Sebastian Bergmann schreibt in der PHPUnit-Dokumentation, dass auf die Funktion tearDown() auch verzichtet werden kann, solange keine externen Ressourcen involviert sind. In den meisten Fällen wird es aber so sein, dass beispielsweise Datenbanken in den Tests beteiligt sind.
Wir testen doch alles, oder?
Die Testfunktionen der vorhergehenden Beispiele überprüften bislang nur, ob die Funktionen das erwartete Ergebnis für einen Standardfall liefern. Bei komplexeren Funktionen gibt es dagegen noch weitere zu überprüfende Aspekte:
| Aspekte | Grund |
| Kontrolle der Funktionalität | Sicherstellen, dass alle Anforderungen erfüllt werden. |
| Exceptions abfangen | Funktionen liefern, z. B. bei illegalen Parametern, Exceptions zurück. Fehlen diese Exceptions, handelt es sich um einen Fehler. |
| Edge-Cases überprüfen | Was passiert, wenn zum Beispiel eine viel größere Zahl übergeben wird als im „Normalfall“? Verhält sich die Funktion genau so wie erwartet? |
| Regression | Gefixte Bugs sollen durch Unit Tests abgedeckt werden. Sollte der Bug erneut auftreten, wird durch den fehlgeschlagenen Test automatisch darauf aufmerksam gemacht. |
Wenn ein Team beginnt, in seinen Projekten Unit Tests einzusetzen, wird anfangs sicherlich die Überprüfung der Anforderungen im Mittelpunkt stehen. Ist genug Zeit vorhanden, können auch noch die Exceptions/Edge Cases geprüft werden. Diese Tests bringen aber häufig sehr viel Aufwand mit sich.
Neben all den Vorteilen, die sauberer Code und die Tests mit sich bringen, gibt es auch einige negative Punkte: Neben dem enormen Aufwand zu Beginn ist mit jeder Änderung am Programmcode meist auch Arbeit an den Tests nötig. Zudem kann die ganze Testerei leicht süchtig machen, was zu noch mehr Tests führt. Die größte Gefahr lauert jedoch in den Tests selbst: Man sollte immer daran denken, dass die Tests von Menschen entwickelt wurden und deshalb ebenfalls Fehler enthalten können.
