Der Unit-Tester

Lange hat sich ja die Idee gehalten, dass ein Entwickler nicht seinen eigenen Code testen kann, da dieser – so die Annahme – ja seinen Code eh nur so (vorsichtig) testen würde, dass sich kein Fehler einstellen würde. Heutzutage ist man davon etwas abgerückt, vor allem wenn der Code auch noch testgetrieben entwickelt wird, da sich hier der Entwickler erst Gedanken über die Verwendung (und über das Design) des Codes macht, bevor er den eigentlichen Code entwickelt. Insofern ist die Testerstellung frei von den Eigenarten der Programmierung. Dazu kommt inzwischen noch die Erkenntnis, dass die Entwickler typischerweise auch gar kein Interesse daran haben, schlechte Tests zu erstellen, da die Unit-Tests (wie erwähnt) als Sicherheitsnetz dienen.

Deswegen ist es üblich, dass die Entwickler die Unit-Tests zu ihrem eigenen Code erstellen. (Wohlgemerkt ich spreche hier ausschließlich von den Modultests und nicht von Tests auf anderen Ebenen wie Integrations- oder funktionalen Tests.) Dementsprechend überrascht war ich neulich, nachdem der Auftraggeber angemahnt hatte, dass es prozentual zum Code zu wenig Unit-Tests geben würde (die Quote lag unter 30 %), als der Projektleiter dann "konsequenterweise" beschloss, noch einen Unit-Test-Entwickler mit an Bord zu holen. Das heißt, in diesem Projekt gibt es nun offiziell die Rolle des Unit-Testers, der für die Klassen und Methoden, die seine Entwicklerkollegen erstellen, Unit-Tests nachzieht.

Die Frage nach der Effizienz und der Verantwortung für die Qualitität des eigenen Codes bleibt dabei jedoch unbeantwortet. ()