Was ist Jasmine?

Jasmine ist ein beliebtes Open-Source-Framework für Behavior-Driven Development (BDD) Tests in JavaScript. Man verwendet es hauptsächlich, um das Verhalten von JavaScript-Code durch das Schreiben von Test-Spezifikationen zu überprüfen. Jasmine bietet eine saubere, leicht verständliche Syntax und ermöglicht Entwicklern, ihre Tests unabhängig von ihrer Implementierung auszuführen. Dadurch können sie schnell und effizient sicherstellen, dass ihr Code wie erwartet funktioniert.

Vorteile:

• Einfachheit: Man hat Jasmine entwickelt, um leicht verständlich und zugänglich für Entwickler zu sein. Die Test-Syntax ist klar und einfach, sodass selbst Entwickler, die neu in der Testautomatisierung sind, schnell damit arbeiten können.
• Unabhängigkeit: Jasmine ist unabhängig von anderen JavaScript–Frameworks, Browsern und DOM-Manipulationsbibliotheken, was bedeutet, dass man es praktisch jedem JavaScript-Projekt verwenden kann, unabhängig von der verwendeten Technologie.
• Flexibilität: Entwickler können Jasmine für Unit-Tests, Integrationstests und sogar für End-to-End-Tests verwenden. Dies gibt ihnen die Möglichkeit, das gesamte Verhalten ihrer Anwendung mit einem einzigen Tool abzudecken.

Wie funktioniert Jasmine?

Jasmine basiert auf einer Hierarchie von Suites und Specs. Suites sind Gruppen von verwandten Tests, während Specs einzelne Testfälle sind. Diese Hierarchie ermöglicht es Entwicklern, ihre Tests klar zu strukturieren und den Code leicht zu organisieren.

Es verwendet das „describe“-Konstrukt, um Test-Suites zu definieren. Jede Suite kann mehrere Test-Spezifikationen (Specs) enthalten, die mit dem „it“-Konstrukt definiert werden. Diese Specs enthalten Erwartungen (Expectations) in Bezug auf das zu testende Verhalten des Codes.

Ein einfaches Beispiel für eine Jasmine Test-Suite sieht wie folgt aus:

describe("A suite is just a function", function() {
  let a;

  it("and so is a spec", function() {
    a = true;

    expect(a).toBe(true);
  });
});

oder

describe('Array', () => {
  describe('#indexOf()', () => {
    it('sollte -1 zurückgeben, wenn der Wert nicht im Array vorhanden ist', () => {
      expect([1, 2, 3].indexOf(4)).toBe(-1);
    });
  });
});

Integration in die Softwareentwicklung

Man kann Jasmine problemlos in moderne JavaScript-Projekte und Build-Tools integrieren. Mit Integrationen für Tools wie Grunt, Gulp und Webpack lässt es sich nahtlos in bestehende Entwicklungsprozesse einfügen. Darüber hinaus gibt es auch Jasmine-Plugins für gängige Entwicklungsumgebungen wie Visual Studio Code oder IntelliJ, die das Schreiben und Ausführen von Tests noch einfacher und bequemer gestalten.

Man kann es auch mit anderen Testing-Tools und Libraries kombinieren, um noch umfassendere Testlösungen zu schaffen. Beispielsweise kann man es mit Karma (einem JavaScript-Test-Runner) verwenden, um Tests in verschiedenen Browsern auszuführen, oder mit Protractor für End-to-End-Tests in Angular-Anwendungen.

Best Practices für Jasmine-Tests

Um das Beste aus Jasmine herauszuholen und effektive Tests zu erstellen, sind hier einige bewährte Vorgehensweisen:

• Klare Testbeschreibungen: Man sollte aussagekräftige und präzise Beschreibungen für Suites und Specs verwenden. Dies erleichtert das Verständnis des Testzwecks und die Identifizierung von Fehlern.
• Kleine, fokussierte Tests: Es ist ratsam, Tests zu schreiben, die nur eine Funktion oder ein Verhalten testen. Dies erleichtert das Auffinden und Beheben von Fehlern, da man dadurch genau im Blick behält, welcher Teil des Codes betroffen ist.
• Testabdeckung: Man sollte sicherstellen, dass man eine ausreichende Testabdeckung für den Code hat. Dies bedeutet, dass man alle wichtigen Funktionen und Szenarien in den Tests berücksichtigt.
• Mocking und Spies: Es ist zu empfehlen, Mock-Objekte und Spies zu verwenden, um externe Abhängigkeiten zu isolieren und den Testfokus auf den zu testenden Code zu richten. Jasmine bietet dafür eingebaute Funktionen wie createSpy und spyOn.
• Regelmäßige Testausführung: Man sollte die Tests regelmäßig ausführen, um sicherzustellen, dass Änderungen im Code nicht zu unerwarteten Fehlern führen. Daher ist es ratsam, Jasmine in den Continuous Integration (CI) bzw. Continuous Deployment (CI/CD) Prozess integrieren, um automatisch Tests auszuführen, sobald man Codeänderungen vornimmt.

Fazit

Jasmine ist ein leistungsstarkes und vielseitiges Framework für das Testen von JavaScript-Anwendungen. Mit seiner klaren Syntax, Flexibilität und Integration in moderne Entwicklungsprozesse ist es ein unverzichtbares Werkzeug für jeden JavaScript-Entwickler. Durch die Befolgung der Best Practices und die regelmäßige Ausführung von Tests können Entwickler sicherstellen, dass ihr Code zuverlässig und fehlerfrei funktioniert. Insgesamt trägt Jasmine dazu bei, die Qualität von JavaScript-Anwendungen zu verbessern und die Entwicklungszeit zu reduzieren.

Der Beitrag Jasmine – JavaScript Testautomatisierung erschien zuerst auf CEOsBay.

Die verhaltensgetriebene Entwicklung kombiniert die allgemeinen Techniken und Prinzipien von TDD. Unter Anderem auch mit Ideen aus dem bereichsgetriebenen Design, der objektorientierten Analyse und dem objektorientierten Design, um Softwareentwicklungs- und Managementteams gemeinsame Tools und einen gemeinsamen Prozess für die Zusammenarbeit bei der Softwareentwicklung zur Verfügung zu stellen.

So wie man die Softwareentwicklung sowohl von geschäftlichen Interessen als auch von technischem Verständnis voranbringt, setzt die BDD-Praxis den Einsatz spezieller Softwaretools zur Unterstützung des Entwicklungsprozesses voraus. Obwohl man diese Tools oft speziell für den Einsatz in BDD-Projekten entwickelt, kann man sie als spezialisierte Formen der Tools zur Unterstützung der testgetriebenen Entwicklung betrachten. Diese Tools dienen dazu, die allgegenwärtige Sprache, die ein zentrales Thema von BDD ist, zu automatisieren.

BDD wird weitestgehend durch die Verwendung einer einfachen domänenspezifischen Sprache (DSL = Domain-Specific-Language) mit natürlichen sprachlichen Konstrukten (z.B. deutsch- oder englischsprachige Sätze) erleichtert, mit denen man das Verhalten und die erwarteten Ergebnisse ausdrückt. Testskripte sind seit langem eine beliebte DSLs mit unterschiedlichem Grad an Raffinessen. BDD gilt als effektive technische Praxis, insbesondere wenn der „Problemraum“ des zu lösenden Geschäftsproblems komplex ist.

Wie funktioniert BDD?

Im Grunde genommen besteht Behavior Driven Development aus den folgenden Elementen:

• Starke Einbeziehung der Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, der Enduser, des Betriebs und von Insidern.
• Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, des externen Verhaltens und des gewünschten Verhaltens der Software.
• Automatisierung der Fallbeispiele unter Verwendung von Mock-Objekten zur Simulation von noch nicht implementierten Softwareteilen.
• Sukzessive Implementierung der Softwareteile und dem Ersetzen der Mock-Objekte.

Dadurch entsteht eine automatisiert prüfbare Beschreibung der zu entwickelnden Software, die jederzeit die Richtigkeit der bereits umgesetzten Teile der Software überprüfen lässt.

Wichtig ist hierbei, dass die Beschreibung nicht die Implementierung der Anwendung vorgibt, sondern den Zweck der Anwendung in Form von Anwendungsbeispielen.

Beim Behavior Driven Development werden die Anforderungen an die Software mittels Beispiele, sogenannten Szenarien beschrieben. Üblicherweise wird für die Beschreibung dieser Szenarien ein bestimmtes Format vorgegeben, damit später die automatisierte Überprüfung der Szenarien einfach umzusetzen ist. Eines dieser Formate ist die Beschreibungssprache „Gherkin“. Man kann es auch in verschiedenen Behavior-Driven-Development-Implementierungen verwenden. Diese Sprache gibt es sowohl mit englischen Schlüsselwörtern (Given, When, Then, And, …), deutschen (Gegeben, Wenn, Dann, Und, …) und in weiteren Sprachen. Mehr dazu in meinem Beitrag über Cucumber bzw. Gherkin.

Fazit

Behavior Driven Development (BDD) ist eine agile Softwareentwicklungs-Methode, die sich auf die Zusammenarbeit zwischen Entwicklern, Business Analysten und Kunden konzentriert, um sicherzustellen, dass die erstellte Software den Bedürfnissen der Anwender entspricht. BDD ist eine Erweiterung des Test Driven Developments (TDD) und legt den Schwerpunkt auf die Definition von klaren, verständlichen Anforderungen und Tests, die das Verhalten der Anwendung aus der Perspektive des Nutzers beschreiben. Durch die Verwendung von gemeinsamer Sprache und konkreten Beispielen kann man die Kommunikation zwischen den Stakeholdern verbessern und Missverständnisse vermeiden. Das Ergebnis ist eine höhere Qualität der Software, eine schnellere Markteinführung und eine höhere Kundenzufriedenheit.

Der Beitrag BDD – Behavior Driven Development – Software, die den Anforderungen der Kunden entspricht erschien zuerst auf CEOsBay.

Cucumber wurde ursprünglich in der Programmiersprache Ruby für Ruby-Anwendungen geschrieben. In der Zwischenzeit unterstützt es aber auch andere Programmiersprachen wie Java und alle anderen auf der Java Virtual Machine gängigen Programmiersprachen sowie C++ und JavaScript. Darüber hinaus gibt es Projekte, die Cucumber noch für weitere Programmiersprachen zur Verfügung stellen und sich als Teil der Cucumber-Familie sehen. Darunter beispielsweise SpecFlow, eine Implementierung für C#.

Wie funktioniert Cucumber?

Wie auch bei den meisten anderen BDD-Frameworks werden in Cucumber Funktionalitäten mittels der Beschreibungssprache „Gherkin“ beschrieben. Gherkin verwendet natürliche Schriftsprache als Grundlage. Lediglich bestimmte Schlüsselwörter werden besonders behandelt.

Gherkin

Gherkin ist die Sprache, die Cucumber verwendet, um Testfälle zu definieren. Sie ist so konzipiert, dass sie sich nicht-technisch und für den Menschen lesbar gestaltet. Es beschreibt Anwendungsfälle in Bezug auf ein Softwaresystem. Der Zweck hinter der Gherkin-Syntax ist die Förderung verhaltensorientierter Entwicklungspraktiken in einem Entwicklungsteam, einschließlich Geschäftsanalysten und Managern. Sie zielt darauf ab, bereits in den ersten Phasen der Anforderungsdefinition durch die Geschäftsleitung und in anderen Phasen des Entwicklungslebenszyklus einer Anwendung feste, eindeutige Anforderungen durchzusetzen.

Syntax

Die Syntax ist ähnlich wie bei Python zeilenorientiert aufgebaut. Die Struktur einer Datei wird durch Leerzeichen und andere Steuerzeichen definiert. # wird als Zeilen bzw. Kommentarzeichen verwendet und kann an jeder beliebigen Stelle in einer Datei stehen. Anweisungen sind jede nicht leere und nicht kommentierte Zeile. Sie bestehen aus einem konkreten Gherkin-Schlüsselwort, gefolgt von einer Zeichenkette.

Alle Gherkin-Dateien haben die Dateierweiterung .feature. Sie enthalten eine einzelne Feature-Definition für das zu testende System und sind ein ausführbares Testskript.

Neben der Bereitstellung eines Skripts für automatisierte Tests ist die Syntax von Gherkin so konzipiert, dass sie eine einfache Dokumentation des zu testenden Codes ermöglicht. Gherkin unterstützt derzeit Schlüsselwörter in Dutzenden von Sprachen.

Schlüsselwörter der Gherkin Sprache

• Feature: Name bzw. die Bezeichnung des Features
• Rule: Regeln des Features
• Example oder Scenario: Die Bezeichnung des Szenarios (Beispielsweise „Die erfolgreiche Anmeldung mit gültigen Anmeldeinformationen.“)
• Given, When, Then, And, But für die steps (oder *)- Vorbedingungen (Gegeben sei), die Aktion, die ausgeführt wird bzw. die Erweiterung durch andere Schlüsselwörter um die Aktion die ausgeführt wird zu ergänzen bzw. zu erweitern. (Der User gibt beispielsweise seine Zugangsdaten, Username and Password ein), gefolgt von der erwarteten Reaktion des Systems (Beispielsweise die Nachricht, bei einem erfolgreichen Login.)
• Background – Ein Background ermöglicht es einem, den nachfolgenden Scenarios einen gewissen Kontext hinzuzufügen. Es kann einen oder mehrere Vorgegebene Schritte enthalten, die vor jedem Scenario aber nach jedem Before hook ausgeführt werden.
• Scenario Outline oder Scenario Template – Damit lässt sich dasselbe Szenario mehrmals mit unterschiedlichen Wertekombinationen ausführen.
• Examples oder Scenarios – Eine Scenario Outline muss einen oder mehrere Abschnitte mit Examples bzw. Scenarios enthalten. Sie dienen als Steps bzw. Interpretationsvorlage, die nie direkt ausgeführt werden. Stattdessen wird die Szenariogliederung einmal für jede Zeile mit den darunter liegenden Abschnitten von Examples ausgeführt.

Gherkin in deutscher Sprache

Um eine Funktionalität auf Deutsch zu schreiben, muss am Beginn des Features # language: de angegeben werden. Damit sind u.A. folgende deutsche Schlüsselwörter verfügbar:

• Funktionalität
• Grundlage
• Szenario
• Szenariogrundriss
• Beispiele
• Angenommen
• Gegeben sei
• Wenn
• Dann
• Und und Aber, sowie *

Die Command line (CL)

Cucumber verfügt über eine integrierte Kommandozeilenschnittstelle, die eine umfassende Liste von Anweisungen enthält. Wie die meisten Kommandozeilen-Tools bietet Cucumber die Option –help an, die eine Zusammenfassung der Befehle liefert, die diese Command Line akzeptiert.

$ cucumber --help
        -r, --require LIBRARY|DIR        Require files before executing the features.
        --i18n LANG                      List keywords for in a particular language.
                                         Run with "--i18n help" to see all languages.
        -f, --format FORMAT              How to format features (Default: pretty).
        -o, --out [FILE|DIR]             Write output to a file/directory instead of
        ...

Fazit

Gherkin ist nicht nur zum Schreiben von automatisierten Tests geeignet. Man kann Gherkin grundsätzlich auch dazu verwenden, um strukturierte Tests zu erstellen, die man später als Projektdokumentation verwendet kann. Erst die Eigenschaft, strukturiert zu sein, gibt uns die Möglichkeit zu automatisieren.

Sowohl die Sprache Gherkin wie auch das Tool Cucumber, bieten weitaus mehr Funktionalitäten, die ich hier nicht thematisiert habe. Zumal ich auch recht frisch in dieses Thema eingestiegen bin. So ist beispielsweise ein Datengetriebenes Szenario mithilfe von Tabellen möglich. Fernab können verschiedene Schritte, die im Prinzip das Gleiche tun, über Platzhalter definiert werden.

Um solche und weitere Vorteile zu nutzen, ist neben Cucumber oder anderen Testtools vor allem Disziplin beim Verfassen der Dokumentation bzw. der Gherkin Dokumente gefragt. Gleichzeitig müssen die formulierten Schritte präzise genug sein, um die gewünschten Verhaltensweisen ausreichend genau zu beschreiben. Ansonsten zerfällt die Abstraktion und Gherkin Dokumente werden lediglich zu etwas besser lesbaren Testskripten statt dem Ansatz des BDD zu folgen.

Cucumber lässt sich auch mit IntelliJ nutzen. Aber darüber gibt es dann in naher Zukunft einen weiteren Beitrag.

Der Beitrag Cucumber – Das kollaborative Tool für Behavior Driven Development erschien zuerst auf CEOsBay.