Kategorien
Unit Tests – Was sollte man testen?
Eigentlich habe ich ja nicht gedacht, dass ich so schnell wieder was über Unit Tests schreibe, aber mir war gerade danach. Vor ein paar Tagen habe ich ja ein wenig aus dem Nähkästchen geplaudert, was die Einführung von Unit Tests angeht. Heute soll es darum gehen zu definieren, was man testen sollte.
Gleich vorne weg, das Beste was man haben kann ist eine 100% Pfadabedeckung, am zweitbesten wäre eine 100% Code Coverage. Und soll ich euch was sagen: Ich glaube kein größeres PHP Projekt hat eines der beiden erreicht. Muss man aber auch gar nicht. Wenn die Kernkomponenten gut getestet sind, dann hat man schon viel gewonnen. 80-90% Codeabdeckung sind immer noch unglaublich gut.
Nehmen wir uns aber den Standardfall vor. Wir haben ein Projekt, das es schon seit Monaten oder Jahren gibt und führen erst sehr spät die Tests ein. Problem erkannt? Im Nachhinein ist es sehr schwer eine hohe Testabdeckung zu erhalten. Sollte man aber trotzdem versuchen den alten Code abzudecken? Meiner Meinung nach ja, aber nicht sofort.
Alter Code wird dann mit einem Test abgedeckt, wenn man ihn erweitert. Sobald man ihn anfasst und/oder refaktoriert, wird ein Test fällig. Was aber noch wichtiger ist, ist das Schreiben von Tests, sobald man einen Bug gefixed hat. Auf diese Weise kann man sicher sein, dass Fehler, die bereits behoben wurden nicht noch einmal auftreten. Solche Tests nennt man übrigens Regressionstests. Wenn man dies eine Weile beherzigt, sollte man alten Code immer besser abgedeckt haben.
Was neuen Code angeht, da bin ich der Überzeugung, dass man alles testen sollte, was neu frisch geschrieben wurde. Ganz einfach.
Wie unterscheidet sich denn eine 100%ige Pfadabdeckung von einer 100%igen Codeabdeckung? Beinhaltet das eine nicht auch das andere?
Eine 100%ige Codeabdeckung sollte man eigentlich immer erreichen können, wenn man sich konsequent an die testgetriebene Entwicklung hält. D.h. auch wenn man einen Bug fixt, sollte man diesen nicht mal eben schnell korrigieren, sondern zuerst den entsprechenden Unittest schreiben, der den Bug nachstellt.
Ich denke, da es zum teil auch mein Problem ist, die meisten Programmierer dürften eher Probleme haben für so manch merkwürdigen Quelltext ein Test zu schreiben, ein refactoring wäre dann zwar wünschenswert aber wahrscheinlich einfach nicht machbar.
@Ralf: Juhu, ich hab ein Thema für Morgen: 100% Pfadabdeckung vs. 100% Codeabdeckung :)Und ja, du hast natürlich Recht, dass TTD hier sehr helfen kann, leider durfte ich es noch nie wirklich in einem „richtigen“ Projekt erproben.
@Salz: Du hast natürlich auch Recht. Was in der Literatur immer als bester Weg genannt wird, ist in der Realität einfach nicht immer realisierbar. Leider meistens wegen Zeitmangel.
Mich würde mal ein kurzes Tutorial interessieren, wie du MVC basierte Webapplikationen testest. Und welche Testsuite bevorzugst du? PHPUnit, SimpleTest, etc.?
Aus meiner Sicht ein sehr interessantes Thema, über das du ruhig mehr schreiben kannst.
Viele Grüße
Tobi
Kleine Anmerkung: Die Tests für den Legacy Code sind bereits _vor_ dem Refactoring oder dem Hinzufügen von neuem Code zu schreiben. Einfach um sicherzustellen, dass die alte Codebasis vom neuen Code verwendet werden kann.
Gerade mit altem Code können einem die Unittests den Tag retten.
Man baut kein Haus auf ein morsches Fundament. Da wird zuerst das Fundament angepackt, falls das Haus weiter benutzt oder erweitert werden soll.
Tobi: Genau das würde ich auch fragen wollen.
„Normale Klassen“ mit ein paar Methoden drin zu testen ist meistens unproblematisch. Was jedoch richtig nervig ist, „alles andere“ zu testen, sprich MVC (vor allem davon das C und V).
Da muß man dann schon mit Tools wie Selenium hantieren, und es ist nicht immer einfach, damit alles abzudecken, vor allem komplizierte Formulare, mehrseitige Formulare etc.
Einfache Beispiele und Anleitungen gibt es [1], aber wünschenswert wären eben auch ein paar umfangreichere, praktische Beispiele, vorzugsweise mit dem Zend Framework.
Ich kann auch nur zustimmen, häufig liegt es am engen Zeitrahmen, der ausführliches automatisiertes Testing verhindert. Laut Theorie (und später auch Praxis) ist es von Vorteil, aber bei einem halbwegs umfangreichen Projekt kostet das Erstellen von Tests schnell mehrere MT, und das will keiner bezahlen (auch wenn man erklärt, dass man dadurch später weniger Bugs (= zufriedenere Kunden) hat und Zeit einsparen wird bei der Bugsuche…)
[1] http://www.phpunit.de/manual/3.3/en/selenium.html
@michael: Zend_Framework hat da in einer der letzten Updates einem das Leben leicht(er) gemacht, mehr schreibt Matthew Weier O’Phinney in „Setting up your Zend_Test test suites“ [1]. Falls man doch lieber auf PHPUnit schielt, dazu hat Federico Cargnelutti
auch bereits einen Ansatz im Artikel „PHPUnit: Testing Zend Framework Controllers“ [2] ausgelassen.
[1] http://weierophinney.net/matthew/archives/190-Setting-up-your-Zend_Test-test-suites.html
[2] http://phpimpact.wordpress.com/2008/12/27/phpunit-testing-zend-framework-controllers/
Was ich auch noch sagen wollte: Wenn keine Tests geschrieben werden braucht sich auch über Tests keine Gedanken gemacht zu werden. Zur Not testet doch immer noch der Kunde, oder? Ist doch gar nicht nötig für die Betriebssicherheit von kommerzieller Software überhaupt was einzuplanen. Lass krachen, Junge!
Aber wenn ich selber meine Bibliothek oder Anwendung entwickle, dann muss ich doch eh testen, ob die Funktioniert. Wer kann eigentlich beim coden belegen das sein Code funktioniert?