Ach ok, das fail() wird da nur ausgelöst wenn die Exception nicht geworfen wird? Ok, dann ist das eine platzsparendere Möglichkeit, auch wenn ich immer noch eher setExpectedException() nutzen würde, ich mag Anweisungen in Annotations nicht so gerne.
Zu den Testmethoden:
Klar, wenn ich für jeden assert eine eigene Testmethode schreibe habe ich gegebenenfalls genauere Angaben was alles bei einer zu testenden Methode nicht passt, weil ich alle fehlgeschlagenen asserts angezeigt bekomme, statt nur den ersten. Das finde ich aber nicht so wild. Entweder besteht eine Methode alle asserts, oder ich muss sie mir sowieso nochmal anschauen, egal ob nun ein assert fehlschlägt oder zwanzig. Ich verstehe aber grundsätzlich dein Argument, du bekommst so präzisere Fehlerberichte.
Ich schreibe zur Zeit tests für ein bestehendes System wo alleine der core weit über 100 zu testende Methoden hat, mit teilweise sehr umfangreichen setup() und teardown()-Methoden. Wenn ich da für jedes assert eine einzelne Methode schreibe komme ich nur für den core auf mindestens 500 test-Methoden. Und ich möchte die tests möglichst schnell halten.
Eure PHP Snippets.
-
-
Jetzt kommen wir ein bisschen zu den Feinheiten von Unittests. Aber etwas offtopic schadet ja nicht.
Es geht nicht nur darum, "feinere Testergebnisse" zu bekommen, sondern die evtl. Fehlersuche- und Erkennung so gut wie möglich zu halten.
Allerdings stehst du ja vor einem anderen Problem, dem Testen von Legacy-Code. Zu umfangreiche setup/teardown Methoden weisen meist auf ein verbesserungswürdiges Design des Programms hin.
Aber seis drum, wir sind kurz vor der Haarspalterei
-
Jetzt kommen wir ein bisschen zu den Feinheiten von Unittests. Aber etwas offtopic schadet ja nicht.
Es geht nicht nur darum, "feinere Testergebnisse" zu bekommen, sondern die evtl. Fehlersuche- und Erkennung so gut wie möglich zu halten.
Allerdings stehst du ja vor einem anderen Problem, dem Testen von Legacy-Code. Zu umfangreiche setup/teardown Methoden weisen meist auf ein verbesserungswürdiges Design des Programms hin.
Aber seis drum, wir sind kurz vor der HaarspaltereiDas Design ist eine ziemliche Katastrophe.
Es geht aber darum die Software mit der aktuellen Funktionalität in eine stabile Version zu kriegen. Sobald die steht werden große Teile des Cores und einige Module sowieso komplett neu geschrieben.
Ist halt immer schön wenn sich bei einem großen Projekt im Laufe der Entwicklung die Zielsetzung grundlegend ändert und die geforderte Funktionalität sich stark erweitert auf Bereiche, die nie geplant waren. Ist ein ziemliches Flickwerk zur Zeit.
