JavaScript Testing auf der IPC 2012 Spring
Kommentare

Martin Ruprecht und Jakob Westhoff haben sich auf der IPC 2012 mit Test Driven Development und Quality Assurance in JavaScript beschäftigt. Ruprecht von der Mayflower GmbH demonstriert den JS Test Driver,

Martin Ruprecht und Jakob Westhoff haben sich auf der IPC 2012 mit Test Driven Development und Quality Assurance in JavaScript beschäftigt. Ruprecht von der Mayflower GmbH demonstriert den JS Test Driver, der sich in alle gängigen IDEs via Plug-in integrieren lässt und testgetriebene Entwicklung ermöglicht. Asserts lassen sich über Formulierungen wie „should return“ einrichten, sodass bei sämtlichen Funktionen sichergestellt wird, dass sie zurückliefern, was sie zurückliefern sollen. Falls Fehler auftreten, kann man sich auf diese Art noch vor dem Deployment ans Refactoring begeben.

Im produktiven Einsatz automatisiert man die Tests oft mit Jenkins. Der Continuous Integration Server lässt die Testsuite nach jedem Commit durchlaufen und liefert einen Testbericht als XML zurück. Nur wenn alle Ampeln grün sind, geht Jenkins mit den Änderungen live. Damit wird das Risiko von Seiteneffekten neuer Code-Segmente reduziert.

Die folgenden Slides zeigen, wie der JS Test Driver mit mehreren Browsern arbeitet und seine Tests in mehreren virtuellen Umgebungen parallel ausführen kann:

Asynchrones Testen erfordert ein paar Tricks, die nur ein Mocking-Tool wie Sinon.js auf Lager hat. Jakob Westhoff von qafoo zeigt, wie diese Test-Helper-Bibliothek über Spies, Stubs und Mocks Rückgabewerte simuliert, Methodenaufrufe überwacht und XMLHttpRequests simuliert, sodass sich die Skripte so verhalten, wie sie in einer produktiven Umgebung arbeiten würden.

So schauen die Spies ganz genau nach, welche Methode wann und mit welchen Parametern aufgerufen wurde. Über Stubs lassen sich einige Methoden unterdrücken, um die übrigen stärker zu isolieren und einzeln testen zu können. Mocks gehen in ihren Funktionalitäten noch etwas weiter als Spies und Stubs und bieten die Möglichkeit, mehrere Erwartungen (Expectations) an Funktionen zu stapeln (stacken), das Calling-Verhalten der Methoden zu validieren und Units in Isolation zu validieren.

Ein Problem beim Unit-Testen von JavaScript Apps ist, dass sie hochgradig integriert sind und von vielen externen Dingen (= Fehlerquellen) abhängig sind. Daher nutzt man Fake Interfaces, die der Unit die Kommunikation mit anderen Teilen vorgaukeln, und diese XMLHttpRequests lassen sich konfigurieren und damit kontrollieren.

Falls Ihr jetzt auf den Geschmack gekommen seid, Euer JavaScript akribisch zu testen, dann schaut Euch evtl. auch Sinon.JS auf Github an. Den JS Test Driver gibt es bei Google Code.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -