Q wie Qualität

JavaScript testgetrieben entwickeln mit QUnit
Kommentare

Sah JavaScript-Entwicklung vor zehn Jahren noch so aus, dass man kleine Codeschnipsel für bestimmte Webseiten entwickelte, geht der Trend seit einiger Zeit dahin, dass modulare JavaScript-Bibliotheken auf vielen Webseiten eingesetzt werden. Eines der prominentesten Beispiele hierfür ist die Bibliothek jQuery. Dieser Beitrag zeigt nach einer kurzen Einführung in das Thema Unit Tests an einem praktischen Beispiel, wie JavaScript modular mit Unit Tests unter Verwendung der QUnit-Bibliothek entwickelt werden kann.

PHP Magazin

Der Artikel „Q wie Qualität“ von Marco Dierenfeldt ist erstmalig erschienen im PHP Magazin 2.2013

Das Thema Unit Tests ist heute jedem Entwickler ein Begriff. Als Test-First-Prinzip im Extreme Programming eingeführt und heute unter dem Begriff Test-driven Development (TDD) bekannt, haben Unit Tests in viele Programmiersprachen Einzug gehalten und sind aus dem professionellen Entwickleralltag nicht mehr wegzudenken. Auch im JavaScript-Umfeld gibt es schon seit ungefähr zehn Jahren Unit-Test-Bibliotheken, z. B. JSTest, das in Anlehnung an JUnit entwickelt wurde. Der Trend zu immer komplexeren und modular aufgebauten JavaScript-Anwendungen hat zur Entwicklung mehrerer Unit-Test-Bibliotheken geführt. Das in diesem Artikel verwendete Framework QUnit ist eine davon.

Welche Vorteile bringen Unit Tests?

Unit Tests sorgen für Sicherheit: zum einen für die Entwickler, die mit dem „Sicherheitsnetz“ Unit Test den bestehenden Code weiterentwickeln können und nach den Änderungen eine Bestätigung über den Test erhalten, dass die Funktionalität erhalten bleibt, sofern der Test erfolgreich durchläuft. Zum anderen bieten Unit Tests dem Qualitätsmanagement die Sicherheit, dass mögliche Fehler im Code oder in der Umsetzung der Anforderungen frühzeitig entdeckt und behoben werden können.

Testgetriebene Entwicklung führt zu höherer Codequalität, da sich der Entwickler, schon bevor der eigentliche Code geschrieben wird, Gedanken darüber machen muss, welches Ergebnis er von dem zu entwickelnden Modul erwartet. Auf diesem Weg wird auch das KISS-Prinzip (KeepItSimple and Stupid) forciert, wodurch der resultierende Code besser strukturiert und robuster wird, was zwei Kriterien für hohe Codequalität sind.

Die Unit Tests stellen auch in gewisser Weise, wenn komplett, eine ideale Dokumentation der Module für Entwickler dar. In den Unit Tests werden schließlich alle Funktionen in der Art und Weise aufgerufen, wie dies der Entwickler erwartet. Wenn bereits bei der Erstellung der Tests mit dem Dokumentationsgedanken im Hinterkopf gearbeitet wird, kann der Dokumentationscharakter durch passende ergänzende Kommentare noch deutlicher gemacht werden.

Obwohl man auf den ersten Blick mehr Quellcode schreiben muss, ergibt sich durch die testgetriebene Entwicklung in der Summe ein Geschwindigkeitsvorteil. Man erhält ihn durch den Vorteil, den geschriebenen Code gleich aufrufen und feststellen zu können, ob er so funktioniert, wie man es erwartet hat oder nicht (fail early). In der klassischen Entwicklung hat man diese Möglichkeit erst dann, wenn der Teil, der den entwickelten Code aufruft, fertig gestellt ist. Oder sogar erst dann, wenn die gesamte Software fertig ist und, in welcher Form auch immer, getestet wird. Im Laufe der Entwicklung einer Software ist es auch oft nötig, bestehende Softwareteile anzupassen. Wie bereits erwähnt, kann dies durch Unit Tests mit einer weit höheren Sicherheit geschehen, was sich natürlich wiederum positiv auf die Entwicklungsgeschwindigkeit auswirkt.

Die wesentlich intensivere Beschäftigung mit dem Quellcode über Unit Tests führt zu einer modulareren Sicht. Entwickler denken in testbaren Einheiten und entwickeln dadurch Software mit höherer Modularität. Dies und die Sicherheit, die uns die testgetriebene Entwicklung bietet, führen dazu, dass Software leichter änderbar und Module besser austauschbar werden.

Gibt es auch Nachteile?

Wo Licht ist, muss auch Schatten sein – so ist es auch mit den Unit Tests. Ein Nachteil ist, dass man durch sie mehr Quellcode in mehr Einzeldateien hat. Das kann dann leicht unübersichtlich werden. Dem kann allerdings durch Namens- und Codekonventionen entgegengewirkt werden. Oft wird auch argumentiert, dass durch das zusätzliche Schreiben von Unit Tests für die Entwicklung mehr Zeit beansprucht würde. Wie bereits erwähnt, ist es aber eher so, dass man im Endeffekt für testgetrieben entwickelte Software weniger Zeit benötigt – oder maximal die gleiche Zeit wie für konventionelle Entwicklung. Selbst wenn man geringfügig länger bräuchte, würde man sich mit dem zusätzlichen Aufwand alle oben beschriebenen Vorteile von testgetriebener Entwicklung sichern.

Unit Tests und JavaScript

Unit-Test-Frameworks für JavaScript sind keineswegs eine neue Erfindung. Schon seit über zehn Jahren gibt es sie. In einer entsprechenden Liste auf Wikipedia [1] werden rund 35 Frameworks aufgezählt. Unter ihnen die bekanntesten: JSUnit, Jasmine und QUnit. Wie eingangs schon erwähnt, möchte ich mich hier auf die QUnit-Bibliothek beschränken. Diese wird als Testframework für die Entwicklung von der jQuery-Familie verwendet und ist auch in vielen anderen Projekten vertreten.


Themen der folgenden Seiten:

  • Testgetriebene JavaScript-Entwicklung mit QUnit
  • Das Beispielprojekt – To-do-Liste
  • Rahmenbedingungen
  • Die Unit-Test-HTML-Seite
  • Erweiterung von unittest.html
  • Unser erster QUnit-Test
  • To-do-Liste
  • Testen des Mockups
  • Persistenz
  • deep Equal
  • Änderungen an „unittest.html“
  • DOM-Manipulation
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -