Das Testbild bei blau

TDD wird bei blau groß geschrieben! Grund genug mal ein wenig über unsere Testinfrastruktur zu erzählen.

Test ist nicht gleich Test

Wir unterscheiden zwischen Unit-, Functional,- und Systemtests. Jede Testart hat ihre Vor- und Nachteile und und erfüllt Ihren Zweck in einem definierten Rahmen.

Unit Tests

Getreu dem Test-First Ansatz schreiben wir so oft wie möglich - es erfordert eben auch Disziplin - den Test zuerst. So gelangt man ganz automatisch dahin, die öffentliche Schnittstelle einer Klasse zu testen. Kollaborateure mocken wir mit EasyMock weg, so das man sich auf die Fachlichkeit der zu testenden Klasse konzentrieren kann. Hier übrigens ein interessanter Artikel von Martin Fowler, darüber, das Mocks eben keine Stubs sind. Häufig sind Testfälle durch das Aufsetzen von Testdaten unnötig aufgebläht. Wir benutzen ein Test-Fixture Pattern aus dem xUnit Pattern Katalog, mit denen die Testdaten an einer Stelle erzeugt und zusammengebaut werden. Damit werden die Tests kleiner und vor allen Dingen wartbarer.

Funktionale Tests

Die Grenzen von Unit Tests sind erreicht, wenn es um das Testen eines ganzen Moduls, z.B. einer Spring Anwendung geht. Mit funktionalen Tests testen wir die öffentlichen Schnittstellen und können damit auch sicherstellen, das z.B. die Spring Konfiguration oder der DB Zugriff korrekt funktioniert. Um auch diese Tests per Knopfdruck laufen lassen zu können (testen muss und soll einfach sein!), wird für den Test eine H2 DB als In-Memory Datenbank und ein Spring Test Context, hochgefahren. Somit ist es möglich, jederzeit Tests auch auf dem lokalen Entwicklerrechner laufen zu lassen, ohne sich um eine vorhandene Infrastruktur Gedanken machen zu müssen. Funktionale Tests betrachten das System bereits als Black-Box und werden auch als Akzeptanztests verwendet.

Systemtests

Nun bleiben noch die spannenden Integrationstests übrig, die sicherstellen, das auch größere Geschäftsprozesse über mehrere Systeme hinweg korrekt funktionieren. In diese Kategorie fallen auch unsere automatisierten Webseitentests mit Selenium und Capybara. Für diese Art von Tests wird eine verfügbare Infrastruktur benötigt, also ein hochgefahrenes Gesamtsystem mit den jeweils richtigen Versionen der Teilsysteme, um eine valide Testaussage treffen zu können. Das Deployment erledigen einige Rubyskripte für uns, die wir an unser Bamboo Buildsystem gekoppelt haben. Die Skripte sind mit einer DSL konfigurierbar, so das alle benötigen Subsysteme autmatisch mit der richtigen Version deployed werden. Im Test können dann direkt die SOAP Schnittstellen der Systeme angsprochen werden. Das alles per Knopfdruck!

Mehr? Aktuelle Artikel oder alle Artikel im Archiv.