© saicle/Shutterstock.com
PHP Magazin
Test-driven JavaScript mit Jasmine

Red, Green, Jasmine

Durch seine weite Verbreitung, seine immer weiter fortschreitende Standardisierung und damit die Reduzierung von Browserinkompatibilitäten ist JavaScript zu einem Kernbestandteil einer jeden Webapplikation geworden. Diese Rolle macht es notwendig, auch den JavaScript-Quellcode unter strengeren Gesichtspunkten zu betrachten, wenn es um Qualität und Zuverlässigkeit geht.

Sebastian Springer


Mit SUnit hat Kent Beck den Grundstein für eine sprachübergreifende Erfolgsgeschichte gelegt. SUnit war das erste Framework der xUnit-Familie von Unit-Test-Frameworks. Es wurde in eine Vielzahl von Sprachen portiert, beispielsweise in Java oder auch PHP. Aber auch für JavaScript existieren mittlerweile verschiedene Implementierungen von Unit-Test-Frameworks dieser Art. Kent Beck hat bei der Erstellung von Unit Tests das Test-driven Development als Vorgehensweise beschrieben. Geht man bei der Entwicklung nach diesen Richtlinien vor, erhält man automatisch eine hohe Abdeckung der Software mit Unit Tests, da sie die Erstellung der Software begleiten und dokumentieren. Des Weiteren zwingt Test-driven Development die Entwickler dazu, sich von vornherein Gedanken über das Design der Software zu machen. Die zugrunde liegende Vorgehensweise wird durch das „Test-driven Development Mantra“ beschrieben: Red/Green/Refactor.

Red/Green/Refactor

Bei Test-driven Development wird, wie bei allen agilen Methoden, in Iterationen vorgegangen. Zu Beginn jeder Iteration steht die Entwicklung eines Unit Tests für eine bestimmte Funktionalität, die allerdings noch nicht im Code vorhanden ist. Ist dieser Test implementiert, werden alle vorhandenen Tests ausgeführt. Der zuletzt eingefügte Test schlägt fehl, da der zu testende Code noch nicht existiert. Das bedeutet, dass der Status der Tests „rot“ ist, also nicht erfolgreich.

Als Reaktion auf den fehlschlagenden Test wird nun Code erstellt, der dafür sorgt, dass der Test erfolgreich durchlaufen wird. Der Fokus liegt dabei darauf, dass lediglich die Anforderungen des Tests erfüllt werden und nicht irgendeine Funktionalität, die in Zukunft irgendwann benötigt werden könnte. Diese Anforderung kann beispielsweise schon durch die Rückgabe eines festen Werts erreicht werden. Nach der Implementierung der Funktionalität werden die Tests erneut ausgeführt. Der Status sollte diesmal „grün“, also erfolgreich sein.

Der dritte und letzte Schritt besteht aus dem Refactoring des Quellcodes. In diesem Schritt wird der bestehende Quellcode aufgeräumt. Diese Aktion sollte sich allerdings nicht nur auf den eben erstellten, sondern auch auf schon länger existierenden Code beziehen. Der letzte Schritt trägt wesentlich dazu bei, die Applikation wartbar und erweiterbar zu halten, indem neuer Code in den bestehenden sauber integriert und der bestehende Code immer wieder überarbeitet wird. Hier kann unter anderem duplizierter Code zusammengefasst oder an ve...

PHP Magazin
Test-driven JavaScript mit Jasmine

Red, Green, Jasmine

Durch seine weite Verbreitung, seine immer weiter fortschreitende Standardisierung und damit die Reduzierung von Browserinkompatibilitäten ist JavaScript zu einem Kernbestandteil einer jeden Webapplikation geworden. Diese Rolle macht es notwendig, auch den JavaScript-Quellcode unter strengeren Gesichtspunkten zu betrachten, wenn es um Qualität und Zuverlässigkeit geht.

Sebastian Springer


Mit SUnit hat Kent Beck den Grundstein für eine sprachübergreifende Erfolgsgeschichte gelegt. SUnit war das erste Framework der xUnit-Familie von Unit-Test-Frameworks. Es wurde in eine Vielzahl von Sprachen portiert, beispielsweise in Java oder auch PHP. Aber auch für JavaScript existieren mittlerweile verschiedene Implementierungen von Unit-Test-Frameworks dieser Art. Kent Beck hat bei der Erstellung von Unit Tests das Test-driven Development als Vorgehensweise beschrieben. Geht man bei der Entwicklung nach diesen Richtlinien vor, erhält man automatisch eine hohe Abdeckung der Software mit Unit Tests, da sie die Erstellung der Software begleiten und dokumentieren. Des Weiteren zwingt Test-driven Development die Entwickler dazu, sich von vornherein Gedanken über das Design der Software zu machen. Die zugrunde liegende Vorgehensweise wird durch das „Test-driven Development Mantra“ beschrieben: Red/Green/Refactor.

Red/Green/Refactor

Bei Test-driven Development wird, wie bei allen agilen Methoden, in Iterationen vorgegangen. Zu Beginn jeder Iteration steht die Entwicklung eines Unit Tests für eine bestimmte Funktionalität, die allerdings noch nicht im Code vorhanden ist. Ist dieser Test implementiert, werden alle vorhandenen Tests ausgeführt. Der zuletzt eingefügte Test schlägt fehl, da der zu testende Code noch nicht existiert. Das bedeutet, dass der Status der Tests „rot“ ist, also nicht erfolgreich.

Als Reaktion auf den fehlschlagenden Test wird nun Code erstellt, der dafür sorgt, dass der Test erfolgreich durchlaufen wird. Der Fokus liegt dabei darauf, dass lediglich die Anforderungen des Tests erfüllt werden und nicht irgendeine Funktionalität, die in Zukunft irgendwann benötigt werden könnte. Diese Anforderung kann beispielsweise schon durch die Rückgabe eines festen Werts erreicht werden. Nach der Implementierung der Funktionalität werden die Tests erneut ausgeführt. Der Status sollte diesmal „grün“, also erfolgreich sein.

Der dritte und letzte Schritt besteht aus dem Refactoring des Quellcodes. In diesem Schritt wird der bestehende Quellcode aufgeräumt. Diese Aktion sollte sich allerdings nicht nur auf den eben erstellten, sondern auch auf schon länger existierenden Code beziehen. Der letzte Schritt trägt wesentlich dazu bei, die Applikation wartbar und erweiterbar zu halten, indem neuer Code in den bestehenden sauber integriert und der bestehende Code immer wieder überarbeitet wird. Hier kann unter anderem duplizierter Code zusammengefasst oder an ve...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang