RESTful Web Services mit JAX-RS. Deutschland 8,50. Project Coin. Verbesserungen in Java 7. Selenium 2 GUI Testing » 100

Transkript

1 inkl. Java Magazin JAVA Mag CD RESTful Web Services mit JAX-RS Deutschland 8,50 Enterprise JavaScript Project Coin Vaadin Mehr unter: RESTful Web Services mit JAX-RS Setzen Sie deshalb auf den neuen Flash Builder 4 und das neue Open Source Framework Flex 4! OSGi-Plug-in-Entwicklung Damit liefern Sie Anwendern genau das, was Unternehmen heute für ihre Kunden suchen: Ebenso einfache wie ansprechende Applikationen. OSGi Plug-ins Schlechte Performance Die anpassbare Anwendung 64 6 Schritte zur Performancebewertung»» 71 Brandneues Programm» 67 OPTIMIERUNG VON JPAANWENDUNGEN Video von der JAX 2010 Test-driven JavaScript Development»24 HIGHLIGHT ActiveMQ 5.5 Selenium 2.0 Vaadin Data Binding mit JavaScript»32 WEITERE INHALTE Node.js Jasmine 1.1 RC1 Aries 0.3 Alle CD-Infos ab Seite 3 Project Coin Verbesserungen in Java 7» 14 Selenium 2 GUI Testing Vaadin 2010 Adobe Systems Incorporated. Alle Rechte vorbehalten. Adobe, das Adobe-Logo, Adobe AIR, AIR, das AIR Logo, Flash, das Flash Logo, Flash Catalyst und Flex sind Marken oder eingetragene Marken von Adobe Systems Incorporated in den USA und/oder anderen Ländern. Alle anderen Marken sind Eigentum der jeweiligen Inhaber magazin Selenium 2 Die Adobe Flash Platform bietet Designern und Entwicklern alle Mittel, um plattformübergreifende, intuitive Rich-Internet-Anwendungen zu entwickeln schneller und besser, anwenderfreundlicher und produktiver. Österreich 9,80 Schweiz sfr 16,80 Java Architekturen Web Agile CD-INHALT Productivity for Professionals» 59» 100 Ein Java-UI-Framework im Visier» 111

2 Testen von und mit JavaScript Test-driven JavaScript Development Immer mehr Anwendungen verwenden JavaScript nicht nur für einfache Validierungen und Ajax-Aufrufe, sondern explizit für die Implementierung einer Controller-Schicht im Client. Und auch auf der Serverseite hält JavaScript mit Projekten wie node.js Einzug. JavaScript ist eine sehr dynamische Sprache, und beim clientseitigen Einsatz sind diverse browserbedingte Unterschiede zu beachten. Deshalb ist es sinnvoll und lohnenswert, bei der Entwicklung von JavaScript-Anwendungen automatisierbare Tests und testgetriebene Entwicklung in den Mittelpunkt zu stellen. Auf die grundlegenden Konzepte der testgetriebenen Entwicklung und der Testautomatisierung wollen wir in diesem Artikel jedoch nicht eingehen, sondern uns auf die Möglichkeiten der Umsetzung bei der JavaScript-Programmierung konzentrieren. von Tobias Bosch und Stefan Scheidt Grundsätzlich benötigen JavaScript-Tests für ihre Ausführung eine entsprechende Laufzeitumgebung, in der Regel eine Browser-Engine. Diese Laufzeitumgebung kann headless sein, das heißt ohne tatsächliche Browseroberfläche, und kann dann beispielsweise leicht in automatisierte Builds auf einem Continuous-Integration-Server eingesetzt werden. Frameworks, die Headless Testing unterstützen, sind beispielsweise HtmlUnit, PhantomJS und Zombie.js. Der Nachteil dieser Ansätze ist jedoch, dass die Laufzeitumgebung für das Ausführen der Tests nicht der Umgebung entspricht, in der der Produktionscode läuft, nämlich die zu unterstützenden Browser. Dieser Nachteil kann durch In-Browser-Tests beseitigt werden, bei denen der zu testende Code zusammen mit dem Testcode durch eine geeignete HTML- Fixture in einen Browser geladen und dort ausgeführt wird. Das Testframework Jasmine ist ein Vertreter dieser Kategorie. In-Browser-Testing ist jedoch nur 2 javamagazin

3 JavaScript Testing Titelthema schlecht zu automatisieren, und an dieser Stelle kommen Frameworks zum Fernsteuern von Browsern ins Spiel. Sie erlauben, die Durchführung von In-Browser-Tests zu automatisieren und das auch parallel für unterschiedliche Browser zu machen. Beispiele hierfür sind Selenium und JsTestDriver. In diesem Artikel werden wir den Einsatz einer Kombination von Jasmine als Testframework und JsTestDriver als Test-Runner demonstrieren. Auch beim serverseitigen Einsatz von JavaScript, beispielsweise mit node.js, besteht die Möglichkeit der testgetriebenen Entwicklung. Darauf wollen wir in diesem Artikel aber nicht genauer eingehen. Das Beispiel Um den Einsatz der genannten Frameworks zu verdeutlichen, soll im Folgenden eine mobile Webapplikation eines fiktiven Fahrzeugverleihs als Beispiel dienen. Zur Webapplikation gehört u. a. ein Formular zur Eingabe der Benutzerdaten (Abb. 1). Diese Daten sollen während der Eingabe validiert werden. Erst wenn alle Eingaben gültig sind, sollen die Daten via Ajax Call an den Server gesendet werden können. Der Client setzt sich aus folgenden Artefakten zusammen: index.html: Das HTML-Markup mit den Eingabeelementen, jedoch ohne JavaScript. model.js: JavaScript, um das Backend anzusprechen. view.js: JavaScript, um auf die Eingabeelemente zuzugreifen. Wenn wir im Folgenden von der View Abb. 1: Formular mit Benutzerdaten javamagazin

4 controller.js: Verbindet die View und das Model und enthält die Fachlogik, in diesem Fall für die Validierung. main.js: Instanziiert Model, View und Controller und verbindet diese. Abbildung 2 verdeutlicht die Zusammenhänge. Der vollständige Quellcode befindet sich unter [1]. Das Beispiel arbeitet absichtlich direkt auf den Browserobjekten ohne den Einsatz von weiteren Bibliotheken wie jquery. Dadurch werden zum einen die Unterschiede zwischen den Browsern deutlicher, zum anderen werden die im Artikel diskutierten Probleme besser sichtbar. Abb. 2: Die Komponenten des Clients sprechen, dann meinen wir diesen JavaScript-Code zusammen mit dem zugehörigen HTML-Markup, das im Browser angezeigt wird. view.js stellt Funktionen zur Verfügung, die die Felder der Oberfläche verändern und auslesen können. Benutzereingaben und Benutzeraktionen werden dabei an den Controller weitergegeben. Listing 1 1 it('should get the field value', function() { 2 var div = document.createelement('div'); 3 document.getelementsbytagname('body')[0].appendchild(div); 4 div.innerhtml = 5 '<input type="text" id="somedata" value="someval">'; 6 var v = view(); 7 expect(v.getfieldstate('somedata').value).toequal('someval'); 8 div.parentnode.removechild(div); 9 }); Listing 2 1 describe("view", function() { 2 var div, v, field; 3 beforeeach(function() { 4 var div = document.createelement('div'); 5 document.getelementsbytagname('body')[0].appendchild(div); 6 div.innerhtml = 7 '<input type="text" id="somefield" value="somevalue">'; 8 v = view(); 9 field = document.getelementbyid('somefield'); 10 }); 11 aftereach(function() { 12 div.parentnode.removechild(div); 13 }); 14 it('should get the field value', function() { 15 field.value = 'somevalue'; 16 expect(v.getfieldstate('someinputfield').value) 17.toEqual('someValue'); 18 }); 19 }); BDD-Testframework Jasmine Die Tests für unser Beispiel implementieren wir mithilfe des JavaScript-Testframeworks Jasmine [2]. Jasmine unterstützt Behavior-driven Development [3]. Damit geschriebene Tests konzentrieren sich auf die Überprüfung des erwarteten Verhaltens der zu testenden Einheit. Die Formulierung der Tests spiegelt das wider, sie erzählt eine Geschichte. Unsere folgenden Beispiele werden das verdeutlichen. Die Entwicklung von Jasmine wurde von diversen anderen Testframeworks beeinflusst: Screw- Unit, JSSpec, JSpec und RSpec. Mehr Informationen über die Anforderungen an ein Testframework, die bei der Entwicklung von Jasmine berücksichtigt wurden, und die dabei verfolgten Ziele befinden sich im Jasmine- Projekt-Wiki. Testen der View Die View (view.js) stellt unter anderem die Funktion get FieldState zur Verfügung, die den Wert und die Fehlermarkierung eines Feldes in der Oberfläche ausliest. Im Folgenden wollen wir die Tests für die View-Schicht vorstellen. In Jasmine werden Testfälle als so genannte Specs bezeichnet (aus dem Englischen: Specification). Um mehrere Specs gruppieren zu können, bietet Jasmine Suites an. In der Jasmine-Syntax sieht das Gerüst für den Test der Funktion getfieldstate dann folgendermaßen aus: describe("view", function() { it('should get the field value', function() {... }); }); Dieses Beispiel definiert eine Suite, die das Verhalten der View beschreibt. Darin ist eine Spec enthalten, die sich auf die View bezieht (it) und prüft, dass die View einen Feldwert korrekt auslesen kann. Man sieht hier sehr schön den BDD-Ansatz, der die Überprüfung des gewünschten Verhaltens in den Vordergrund stellt. Die ganze Spec ist in Listing 1 zu sehen. Zunächst wird ein neues Eingabefeld an das Ende des aktuellen Dokuments angefügt (Zeile 2 bis 5). Der Grund dafür ist, dass Jasmine von sich aus keine Bereitstellung eines HTML-Dokuments als Fixture für einen Test unterstützt. Diese Funktionalität könnte durch Jasmine Add-ons nachgerüstet werden [4], [5]. Darauf wol- 4 javamagazin

5 len wir in unserem Beispiel jedoch verzichten. Darüber hinaus erreichen wir durch die von uns gewählte Vorgehensweise, dass unsere Tests echte JavaScript-Unit- Tests sind, die keine Abhängigkeiten zu spezifischem HTML-Markup haben. Statt dessen stellen wir den vom Test erwarteten Zustand des DOM im Test selber her. In Zeile 6 wird dann eine neue View-Instanz erstellt, in Zeile 7 die zu testende Funktion aufgerufen und deren Ergebnis geprüft, schließlich wird in Zeile 8 das erzeugte Eingabefeld wieder entfernt. Prüfungen werden mithilfe der so genannten Matcher geschrieben. Ein Matcher führt eine Prüfung auf dem Objekt durch, das als Parameter an die Funktion expect übergeben wurde. Dadurch lassen sich ganz im Sinne von BDD gut lesbare Subjekt-Prädikat-Objekt- Sätze ausdrücken. Es existieren viele direkt verwendbare Matcher wie toequal, tobetruthy, tobelessthan und so weiter. Die Matcher können durch das Voranstellen der Funktion not negiert werden, z. B. expect(x).not. toequal(y). Falls es für eine Prüfung keinen passenden Matcher gibt, können diese beliebig erweitert werden. Spätestens bei der zweiten Spec in der Suite fällt auf, dass immer derselbe Initialisierungs- bzw. Finalisierungsteil benötigt wird: Anlegen eines Eingabefeldes bzw. Entfernen des Eingabefeldes und die Erstellung der View. Hierfür bietet Jasmine die Funktionen before Each bzw. aftereach. Das Beispiel oben kann nun wie in Listing 2 umgestellt werden. Die eigentliche Spec setzt nur noch einen Wert in dem Feld und führt die Prüfung durch. Test des Controllers: Spies Im Folgenden erläutern wir die Tests der Controller- Schicht. Um den Controller isoliert zu testen, werden Stellvertreterobjekte für das Model und die View benötigt, da der Controller diese Objekte verwendet. Jasmine stellt dafür die so genannten Spies (Spione) zur Verfügung. Dabei handelt es sich um Funktionen, deren Aufruf Jasmine aufzeichnet und für spätere Prüfungen zur Verfügung stellt. Die Funktion spyon(obj,fnname) ersetzt die Funktion mit dem Namen fnname im Objekt obj durch einen Spy und gibt diesen auch als Rückgabewert zurück. Am Ende des Tests werden diese Änderungen am Objekt automatisch wieder rückgängig gemacht. Zur Definition des Verhaltens des Spys stellt Jasmine diverse Funktionen zur Verfügung (Tabelle 1). Das besondere an Spies ist, dass sie alle Aufrufe aufzeichnen und diese später für Prüfungen zur Verfügung stellen. Tabelle 2 listet die mitgelieferten Matcher für Spies auf. Tabelle 3 zeigt, wie Spies geprüft werden können, die gegebenenfalls mehrfach aufgerufen werden. Zurück zum Test des Controllers. Die Funktion validate des Controllers liest Werte aus der View aus, validiert sie und markiert fehlerhafte Felder in der View. Um diese Funktion zu testen, müssen also die Funktionen zum Lesen und Schreiben von Werten in der View durch Spies ersetzt werden: var v = view(); spyon(v, 'getfieldstate'); spyon(v, 'setfieldstate'); Welche Felder vorhanden sind und welche Validierungsregeln angewendet werden sollen, bekommt der Controller als Parameter bei der Erzeugung mitgeteilt. In diesem Testfall soll der Controller für das Feld name prüfen, ob es gefüllt ist: var c = controller({name: 'required'}, v, model());. Damit lässt sich dann auch schon ein erster Testfall für die Validierung von Pflichtfeldern im Controller schreiben (Listing 3). Die Überprüfung geschieht in der letzten Zeile des Codeblocks. Es wird geprüft, ob nach der Erzeugung des Controllers die Methode setfieldstate der View v mit den Parametern 'name' und {error: true} aufgerufen wurde. Funktion Der Spy soll... spy.andcallthrough()... die ursprüngliche Funktion aufrufen spy.andreturn(argument)... das übergebene Argument zurückgeben spy.andthrow(exception)... die übergebene Exception werfen spy.andcallfake(function)... die übergebene Funktion aufrufen Tabelle 1: Funktionen von Spies Funktion Prüft, ob der Spy... tohavebeencalled()... aufgerufen wurde tohavebeencalledwith(arguments)... mit den übergebenen Argumenten aufgerufen wurde Tabelle 2: Matcher für Spies Eigenschaft Bedeutung spy.callcount Anzahl der Aufrufe spy.argsforcall[i] Argumente des i-ten Aufrufs spy.mostrecencall.args Argumente des letzten Aufrufs Tabelle 3: Eigenschaften von Spies Test des Models: asynchrone Tests Das Model verwendet XMLHttp Request, um mit dem Backend zu kommunizieren. Da die Hauptaufgabe des Models darin besteht, das Backend aufzurufen, soll der Test für das Model auch tatsächlich das Backend aufrufen. Dazu muss der Test in der Lage sein, auf das Ergebnis des Models zu warten. Im Gegensatz zu Programmiersprachen wie Java ist JavaScript Single-Threaded und kann damit den aktuellen Ausführungs-Thread auch nicht anhalten. In JavaScript werden stattdessen Events und Callbacks verwendet. Damit Jasmine während der Ausführung von Tests warten kann, 5 javamagazin

6 JavaScript Testing Titelthema müssen die Tests in Abschnitte unterteilt werden, zwischen denen jeweils gewartet werden soll. Diese Abschnitte werden über die Funktion runs in einer internen Verarbeitungswarteschlange von Jasmine registriert. Das Warten selber erfolgt ebenfalls über eine Callback- Funktion, die von einem Timer in regelmäßigen Abständen aufgerufen wird. Das Warten ist beendet, sobald die Wartefunktion true zurückgibt. Die Wartefunktion wird über die Funktion waitsfor bei Jasmine registriert. Einen Test für das Model, der diese Konzepte verwendet, zeigt Listing 4. Der erste Teil des Tests ruft die Funktion savecustomer des Models auf. Als Parameter werden das zu speichernde Kundenobjekt und ein Callback übergeben (Zeile 3 bis 8). Wenn der Serveraufruf zu Ende ist, ruft das Model den übergebenen Callback auf und übergibt ihm den aktuellen Kunden. Der Callback speichert den Kunden in einer Variablen, die von allen runs- und waitsfor-funktionen lesbar ist. Nach diesem ersten Teil soll der Test warten, bis das Model den Kunden erfolgreich gespeichert hat. Dafür wird eine Funktion definiert, die dann true zurückgibt, wenn das Model den Serveraufruf beendet hat (Zeile 9 bis 11). Falls die Wartezeit mehr als 4000 Millisekunden beträgt, wird der Test mit der Fehlermeldung Server Call never completet beendet. Der letzte Teil des Tests führt die eigentliche Prüfung des Tests durch (Zeile 12 bis 14). In diesem Fall wird geprüft, ob vom Server eine ID vergeben wurde. Das Ausführen der Jasmine Specs Jasmine setzt für die Ausführung von Tests kein DOM (Document Object Model) voraus und kann daher beispielsweise auch mit node.js benutzt werden. Dafür gibt es ein entsprechendes node.js-modul. Die einfachste Möglichkeit, Jasmine Specs in einem Browser auszuführen, besteht darin, sie in einer vom Projekt bereitgestellten HTML-Seite SpecRunner.html einzutragen und diese Seite dann in einem Browser zu öffnen. Diese Vorgehensweise eignet sich vor allem für Ad-hoc-Tests und um Tests im Browser zu debuggen. Wenn dem Einsatz von Ruby nichts im Weg steht, dann gibt es insbesondere für die Nutzung in Rails-Projekten ein Ruby Gem, das bei Bedarf ein Projekt initialisiert, zum Ausführen der Tests einen Webserver startet und die Specs für einen Continuous Integration Build mithilfe von Selenium automatisiert in einem Browser ausführen kann. Für Javabasierte Projekte gibt es ein Maven-Plug-in, das einen HTML Spec Runner für die manuelle Ausführung der Specs generiert. Darüber hinaus führt es die Specs im Rahmen eines Maven Builds automatisch mithilfe von HtmlUnit, also headless aus. In unserem Beispiel möchten wir die Tests aber sowohl automatisiert in Rahmen eines CI-Builds als auch in mehreren echten Browsern ausführen können, um Fehler durch unterschiedliches Verhalten der Browser und Unterschiede bei den bereitgestellten APIs zu finden. Die Lösung für dieses Problem wird durch JsTestDriver bereitgestellt. Test-Runner JsTestDriver für Cross-Browser-Tests JsTestDriver [6] ist ein JavaScript-Test-Runner, der die automatisierte parallele Ausführung von Tests in mehreren Browsern unterstützt. Die Tests können dabei unter anderem über die Kommandozeile und auch im Rahmen eines Continuous Builds ausgeführt werden. Um eine häufige Ausführung der Tests nicht zu behindern, legt das Projektteam von JsTestDriver großen Wert auf eine schnelle Testausführung. Die Verwendung von JsTest- Driver gestaltet sich wie folgt: 1. Zunächst muss der JsTestDriver-Server gestartet werden. Dabei handelt es sich um einen Java-Prozess, der einen konfigurierbaren Port zur Kommunikation öffnet. Auf der Kommandozeile kann der Server beispielsweise wie folgt gestartet werden: java -jar JsTestDriver.jar --port Anschließend kann man einen oder mehrere Browser mit dem Server verbinden, der diese dann zur Test- Listing 3 it('should mark empty required fields with an error', function() { var v = view(); spyon(v, 'getfieldstate').andreturn({value:''}); spyon(v, 'setfieldstate'); var c = controller({name: 'required'}, v, model()); expect(v.setfieldstate).tohavebeencalledwith('name', {error: true}); }); Listing 4 1 it('should save a customer and assign an id', function() { 2 var savedcustomer = null; 3 runs(function() { 4 model().savecustomer({ name: 'a', 'a@b.c'}, 5 function(customer) { 6 savedcustomer = customer; 7 }); 8 }); 9 waitsfor(function() { 10 return savedcustomer!= null; 11 },'server call never completed',4000); 12 runs(function() { 13 expect(savedcustomer.id).tobetruthy(); 14 }); 15 }); Listing 5 server: load: - src/*.js - src-test/*.js javamagazin

7 wir alle von uns gesteckten Ziele: Wir haben Zugriff auf das Document Object Model, da die Tests in Browsern ausgeführt werden. Die Tests können parallel in allen Browsern ausgeführt werden, in denen wir unsere Anwendung überprüfen wollen, und die Testausführung kann automatisiert im Rahmen eines CI-Builds durchgeführt werden. Abb. 3: Überblick über JsTestDriver [6] ausführung fernsteuern kann. Im Beispiel ruft man dazu den URL auf. 3. Im JavaScript-Projekt, in dem man Tests ausführen möchte, erstellt man eine Konfigurationsdatei im YAML-Format, in der man den zu verwendenden JsTestDriver-Server und die JavaScript-Dateien mit Produktions- und Testcode, die geladen werden sollen, angibt. Bei der Angabe der JavaScript-Dateien werden Platzhalter unterstützt, sodass diese Datei in einem Projekt selten aktualisiert werden muss. Im einfachsten Fall sieht die Konfigurationsdatei wie in Listing 5 aus. 4. Jetzt können die Tests mithilfe eines Java-Prozesses ausgeführt werden. Dabei werden die angegebenen JavaScript-Dateien über den JsTestDriver-Server an alle angeschlossenen Browser übermittelt, dort ausgeführt und die Ergebnisse wiederum über den Server an das Projekt zurück gegeben. Auf der Kommandozeile können die Tests mit java -jar JsTestDriv er.jar --tests all ausgeführt werden. Abbildung 3 verdeutlicht die Zusammenhänge. Steht Ruby zur Verfügung, so kann einem das Ruby-Gem jstdutil die Arbeit erleichtern. Es erlaubt den Start des Servers und bietet einen Autotestmodus, in dem alle Tests ausgeführt werden, sobald sich eine JavaScript- Datei im Projekt ändert. Für Eclipse und IntelliJ stehen Plug-ins zur Verfügung, um JsTestDriver aus der IDE heraus zu nutzen, und für Maven-Projekte gibt es ein Maven-Plug-in, dessen Einsatz von unserem Beispielcode demonstriert wird. Zusätzlich zu den Test-Runner-Funktionalitäten bietet JsTestDriver auch JavaScript-Funktionen zum Implementieren von Tests und lehnt sich dabei an JUnit an. Darauf wollen wir in diesem Artikel jedoch nicht eingehen. Stattdessen verwenden wir einen Adapter für JsTestDriver und Jasmine, der es erlaubt, unsere mit Jasmine formulierten Tests mit JsTestDriver ausführen zu lassen [7]. Dazu ist lediglich die Jasmine- und die Adapter-JavaScipt-Datei dem Projekt und der Js- TestDriver-Konfiguration hinzuzufügen. Durch diese Kombination von JsTestDriver und Jasmine erreichen Fazit Grundsätzlich gehört automatisiertes Testen und testgetriebene Entwicklung heutzutage zum Handwerkszeug professioneller Softwareentwickler. Aber gerade im Umfeld der sehr dynamischen Sprache JavaScript und den sich teilweise immer noch sehr unterschiedlich verhaltenden Laufzeitumgebungen ist es geradezu unverzichtbar. Mit Jasmine als Testframework für Behaviour-driven Development und JsTestDriver als Multibrowser-Test-Runner stehen einem sowohl für die Implementierung als auch die kontinuierliche Ausführung von Unit Tests mächtige Hilfsmittel zur Verfügung, die aus unserer Sicht nahezu alle Anwendungsfälle abdecken. Die Ausführung von Oberflächentests ist mit Jasmine unter Verwendung von Add-ons wie jasmine-ui [5] ebenfalls möglich. Testgetriebene Entwicklung ist ein wichtiger Baustein für die Entwicklung qualitativ hochwertiger Software. Ein weiterer Baustein sind Entwurfsmuster, die dabei helfen, dass Software auf lange Zeit wart- und testbar bleibt. Der Artikel Data Binding mit JavaScript (siehe S. 32) stellt ein solches Entwurfsmuster vor und beschreibt, wie es in JavaScript-Anwendungen verwendet werden kann. Tobias Bosch ist Senior Consultant bei der OPITZ CONSULTING GmbH. Er beschäftigt sich seit mehreren Jahren mit Architektur und Implementierung von Enterprise-Applikationen auf Basis von Java. Seine Schwerpunkte sind Java-EE- und HTML5-Anwendungen. Stefan Scheidt ist Solution Architekt bei der OPITZ CONSULTING GmbH. Er beschäftigt sich seit mehreren Jahren mit Architektur und Implementierung von Enterprise-Applikationen auf Basis von Java. Seine Schwerpunkte sind Java EE, das Spring Framework und Mobile Computing. Links & Literatur [1] Vollständiger Quellcode zum Beispiel: [2] Jasmine-Homepage: [3] Behaviour-driven Development: Driven_Development [4] Jasmine Add-on jasmine-jquery: [5] Jasmine Add-on jasmine-ui: [6] JsTestDriver-Homepage: [7] Jasmine-JsTestDriver-Adapter: 7 javamagazin