Projektwerkstatt: Dynamic Smoke Tests

Wie so oft, hat mein Gehirn mal wieder Sonderschichten gefahren und ohne dass ich es wollte kam ich auf eine Idee. Wir sind gerade dabei unsere funktionalen Tests von manuellen Testdurchläufe auf automatisierte zu migrieren. Wir haben und Selenium, CasperJS und Codeception genau angeschaut. Dazu aber wann anders mehr. Zumindest falls es euch interessiert.

Jetzt noch kurz eine Begriffserklärung, bevor es losgeht. Ein Smoke Test ist ein Test, der die grundlegenden Eigenschaften einer Applikation testet. Wenn dieser schief läuft, dann braucht man gar nicht weiter testen und sollte Alarmglocken anwerfen. Wie packen also die Tests für die riskanten Features dort rein. Dinge, die teuer sind, wenn sie ausfallen und Dinge, die häufig kaputt gehen. Risiko ist ja schließlich das Produkt aus Eintrittswahrscheinlichkeit und Kosten.

Meine Idee ist eigentlich ganz einfach. Wenn man eine funktionale Testsuit hat, dann kann es schon mal sein, dass ein gesamter Testdurchlauf mehrere Stunden dauert. Wie müssen ja immer den Browser anwerfen und die Seiten auch tatsächlich rendern. Das ganze Warten kostet eben Zeit. Smoke Tests, die nicht alles testen, sind also ein wichtiges Werkzeug. Ein klassisches Continuous-Integration-Setup sieht so aus, dass man die Smoke Tests commitgetrieben ausführt und Nachts einen nightly build erstellt, der vollumfänglich getestet wird.

Was ich jetzt will ist eine Erweiterung für Codeception (ja unsere Wahl ist auf dieses Tool gefallen), die die Tests markiert, die in den Nightly Builds schieflaufen. Diese Tests werden dann automatisiert zu den Smoke Tests hinzugefügt. Falls sie die nächste zwei Wochen nicht anschlagen, dann werden sie auch wieder automatisiert rausgenommen. Einfach und effizient würde ich sagen. Ich werde das wohl bauen.

Warum ist das so effizient? Sobald ich an einem Feature arbeite, wird es kaputt gehen. Und dann ist es natürlich praktisch, wenn die ganze Zeit, an der ich daran arbeite die Tests zu dem Feature auch ausgeführt werden. Und das möglichst oft. Das Feature hilft einem also dabei, die Tests auszuführen, die die Features abdecken, an denen man gerade arbeitet. Und das automatisch.