Facebook
Twitter
Google+
Kommentare
0
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

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.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen