Kategorien
Eigentlich machen wir schon Unit Tests
Heute geht’s mal wieder um ein Verkaufsargument für Unit Tests. Wir alle kennen das Gerücht, dass Unit Tests das Entwickeln langsamer machen und deswegen unter Druck zu vernachlässigen sind. Finden wir alle ganz doof, aber meistens haben wir ja eh nichts zu sagen und es muss eh ein anderer seinen Kopf dafür herhalten.
Ich will jetzt mal die provokante These in den Raum stellen, dass ihr in vielen Fällen bereits so eine Art Unit Tests macht, ohne es wirklich zu wollen. Zumindest kann ich da ein Lied von singen.
Wir sind ja alle große Freunde von loser Kopplung und Komponenten, sollte man zumindest sein, wenn man gute Software schreiben will. Bei mir ist es dann so, dass ich, wenn ich mal wieder eine neue Komponente schreibe, mich dabei erwische wie ich allen möglichen Code in ein einfaches PHP-Skript packe, um zu schauen, ob das was ich programmiert habe auch funktioniert. Mein tmp-Verzeichnis ist oft voll mit Dateien wie test.php, runner.php, component1.php. Dort lege ich mir einfach Code-Snippets ab, mit denen ich rumspiele. Ich könnte meinen Prüf- bzw. Testcode natürlich auch direkt in der Applikation reinklatschen, da das so aber leichtgewichtiger ist und ich nichts kaputt mache. Als ich Annovent entwickelt habe, standen zum Beispiel diese Code-Schnippsel in einer Datei.
Wie geht man mit so einer Datei um? Man programmiert und schaut, ob die Zeile Testcode jetzt das macht, was man haben will. Wenn das Feature fertig ist, wird die Zeile gelöscht und der nächste Testcode geschrieben. Aber eigentlich ist genau das ja Unit Testing. Ich habe einen Aufruf und prüfe, ob mein Erwartungswert gleich dem tatsächlichen Wert ist.
Warum also nicht den Testcode anstatt in einer runner.php gleich in einen Unit Test verpacken und diesen aufrufen. Dort hat man viel bessere Möglichkeiten zu prüfen, ob das Ergebnis valide ist. Nach der Verwendung auch nicht löschen, einfach den nächsten Test anfangen.
Dem kann ich soweit zustimmen, ich habe das früher auch oft so gemacht. Inzwischen habe ich es mir angewöhnt Komponenten gleich mit UnitTests zu testen. Die haben dann in der Entwurfsphase vielleicht nur einen Test wo alles Mögliche drin steht, aber nach und nach verfeinert es sich dann. Hat ja auch den Vorteil, dass sich die Komponente gleich in der „realen“ Welt beweisen kann.
Wenn ich in den letzten Jahren was gelernt habe, dann dass es zu jedem Thema auch ein „ja, aber…“ gibt. In dem Fall ist es dann nicht das Schreiben der Tests an sich, sondern die angeblich „so aufwändige“ Installation von PHPUnit.
Ich kenne die Situation und habe mich gerade gefragt, was mich im „quick and dirty“-Modus davon abhält, PHPUnit zu nutzen. Das eine ist, dass ich die ganzen Assertions nicht auswendig weiß, ein schlechtes Gefühl dabei habe, immer nur „assert“ zu verwenden und ich die Doku etwas zu unübersichtlich finde. Ein Cheat Sheet muss her. Die andere Überlegung war die Struktur von Tests – wie muss ein Testcase aufgebaut sein, von vom erbt er, etc. Das weiß ich derzeit auch nicht auswendig. Das ist aber dank der Parameter „–skeleton-class“ und „–skeleton-test“ ein gelöstes Problem.
Genauso ging es mir auch: irgendwann fragte ich mich, aufmerksam geworden durch die Unit Test Artikel in PhpHatesMe, warum ich das was ich immer in ine test.php datei schreibe nicht auch gleich in Unit Tests packe. Und so bin ich jetzt ein glücklicher Test Schreiber 😉
Du musst schon zugeben, dass es einen erheblichen Implementierungsunterschied macht, ob ich beim Schreiben der Tests Mocks erstelle, die die Dependencies simulieren, oder ob ich mal mit einem Test-Skript 1-2 Use-Cases mit dem kompletten Call Stack bis zur Datenbank teste. (Letzteres ist kein Unit-Test) Nichtsdestotrotz sind die Use-Case-Tests, von denen du redest, durchaus hilfreich und sollten im automatisierten Testframework abgelegt werden.
Hi,
genau deine Gedanken hatte ich vor ein paar Tagen auch mal wieder.
Du triffst den Kern und eigentlich versteht man schwer, was sich viele Leute dann trotzdem so schwer tun mit dem Thema.
Also ich sehe da auch einen Unterschied, da die meisten kurz verwendeten Testskripte ja keine klassischen, in sich abgekapselten Unit-Tests einer Einheit darstellen, sondern eher in die Richtung von Integrationstests gehen.
Ich sehe es allerdings als absolut legitim, diese „temporären Tests“ zu verwenden, und die Snippets dann an die richtige Stelle in die Unit-Tests zu migrieren.
Von einer Ablegung in ein Testframework halte ich allerdings nichts, da solche die Übersichtlichkeit und damit ja auch (meiner Meinung nach) die Wartbarkeit, was einer der, wenn nicht das, Hauptargument für Unit-Tests darstellen, verschlechtern.