Entdecke die Möglichkeiten!

JavaScript Testing im Aufwind (Teil 2)
Kommentare

Windows Developer

Der Artikel „JavaScript Testing im Aufwind“ von Sebastian Springer ist erstmalig erschienen im Windows Developer 7.2012
Im JavaScript-Umfeld existieren seit mehreren Jahren namhafte

Windows Developer

Der Artikel „JavaScript Testing im Aufwind“ von Sebastian Springer ist erstmalig erschienen im Windows Developer 7.2012

Im JavaScript-Umfeld existieren seit mehreren Jahren namhafte Frameworks für Unit Tests wie bspw. JsUnit. Es zeichnet sich bis jetzt leider noch kein Trend zu einem einzigen, projektübergreifenden Tool ab, wie es in der PHP-Welt mit PHPUnit bereits seit Jahren existiert.

Dieses Problem wird vor allem durch die Tatsache verschärft, dass nahezu jedes JavaScript-Framework sein eigenes Testframework mitbringt. So laufen Unit Tests unter jQuery mit QUnit; Dojo benutzt doh, YUI nutzt YUItest. Darüber hinaus tragen frameworkunabhängige Tools wie JsUnit, J3Unit oder Jasmine ihren Teil zur Vielfalt bei.

Unabhängig vom verwendeten Framework sind die Voraussetzungen für Unit Tests in JavaScript überall dieselben. Der wichtigste hier zu nennende Punkt ist testbarer Code. Quellcode muss bestimmte Kriterien erfüllen, damit er durch Unit Tests abgesichert werden kann. Denn nicht jedes Codefragment ist per se testbar.

Die Basis bildet eine saubere Trennung von Logik, Auszeichnung und Layout. Das bedeutet im Regelfall, dass sämtlicher JavaScript-Code in separaten .js-Dateien liegt, das Gerüst der Seite in HTML geschrieben und in .html-Dateien abgelegt ist und das Layout über CSS in den entsprechenden .css-Dateien definiert wird.

So ergibt sich die Möglichkeit, seinen JavaScript-Code unabhängig von den übrigen Komponenten zu testen. Es wird hier nach dem Prinzip entwickelt: Nur wenn die kleinste Einheit für sich funktioniert, kann auch die gesamte Applikation fehlerfrei laufen. Um eine gute Testbarkeit des Quellcodes zu gewährleisten, ist darauf zu achten, dass die erstellten Klassen sich auf einen bestimmten Zweck konzentrieren und damit eine Gruppierung logischer Einheiten darstellen.

Es sollte vermieden werden, innerhalb einer Klasse verschiedene Themengebiete abzudecken. Es gilt: pro Quellcodedatei nur eine Klasse. Diese bleibt in sich konsistent, was zu einer sauberen Strukturierung der Applikationslogik beiträgt (engl. „Separation of Concerns“).

Dependency Injection

Als letzter Baustein soll hier noch auf die Dependency Injection eingegangen werden. Dieses Struktur-Pattern beschreibt, dass die Abhängigkeiten einer Methode über Parameter in die Methode einfließen und nicht innerhalb der Methode direkt aufgelöst werden sollten. Hier spricht man von „loser Kopplung“.

Die verschiedenen Komponenten sind bis auf Schnittstellen unabhängig voneinander, was die Applikation robuster macht und die einzelnen Methoden flexibler hält, da verschiedene Abhängigkeiten übergeben werden können. Auf diese Weise werden die Tests leichtgewichtiger, da externe Abhängigkeiten einfacher aufzulösen sind.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -