Tests scheint irgendwie niemand gerne zu machen. Warum auch immer. Das sehe ich gerade jetzt wieder. Ich betreue ja wieder mal das Softwareentwicklungsprojekt und da soll im Team eine Software entwickelt werden. Und selbstverständlich muss man die auch testen (das schreiben wir sogar vor). Hier aber mal eine kurze Statistik, wie das aussieht:

• Innerhalb von ca. 2 Wochen haben von den 17 Gruppen gerade mal 5 überhaupt angefangen, Tests zu schreiben.
• Davon benutzen gerade mal zwei Stubs.
• Dafür hat eine Gruppe ganz offensichtlich schon Probleme, das Prinzip von JUnit zu verstehen
• Und eine hat bisher nur ein paar Fingerübungen gemacht.

Wir kannten solche Probleme schon aus den letzten Jahren. Also hatten wir extra eine Saalübung zum Thema Testen gemacht. Wir hatten erklärt warum man testet, wie man das tut, wie und warum man Stubs verwendet und warum Test-First eine sinnvolle Strategie ist. Geholfen hat es offensichtlich wenig. 🙁

Dabei könnten Unit-Tests helfen, Zeit zu sparen, weil man Bugs früher bemerkt. Ja genau: Richtig eingesetzt würden die Tests eigentlich Zeit sparen. Eigentlich…

Ich will jetzt aber wenigstens noch ein bisschen was zu Tests sagen. Nicht weil ich große Hoffnung hätte, dass das auf wundersame Weise 17-x SEP-Gruppen bekehrt (die meisten werden das hier wohl eh nicht lesen). Aber ich hab ein paar interessante Links, die vielleicht wenigstens *irgendwem* helfen könnten…

• Nich Hodges beschreibt ganz anschaulich die wichtigsten Begriffe: The Vocabulary of Unit Testing
• Mocks Aren’t Stubs: Mal wieder Martin Fowler. Hier über unterschiedliche Arten von Dummy-Objekten. Das geht schon ein bisschen mehr ins Detail.
• In TestPyramid erklärt Martin Fowler, warum die meisten Tests Unit-Tests sein sollten.
• Wenn man das falsch macht, wird aus der Pyramide schnell ne Eiswaffel.
• Bei den meisten SEP-Gruppen ist es noch schlimmer: Keine Unit-Test machen, ist, wie ein langsam schmelzendes Bällchen Eis ohne Waffel in der Hand zu halten…
• Ich höre oft, dass bestimmte Tests einfach nicht gemacht werden, weil das „nicht testen geht“. Meistens ist das ne Ausrede. Oft zeugt es auch von falschem Design (Testability ist eine der „Illities“, die gutes Design auszeichnen).
• Manchmal werde ich gefragt, ob man Getter- und Setter-Methoden überhaupt noch testen müsse. Die sind ja trivial. Das kann man durchaus so sehen. Dann sollte man die gewonnene Zeit aber in bessere Tests für das nicht-triviale Zeug investieren.
• Ähnlich ist es mit dem Testen von GUIs. Das ist nicht ganz einfach (auch, wenn es dafür Frameworks wie Selenium gibt). Man kann sich deshalb auf den Standpunkt stellen, dass subkutane Tests reichen.
• Insbesondere sollte man auch Fehler- und Grenzfälle testen. Das sind nämlich die, die am ehesten Probleme machen.
• Mal so als Anhaltspunkt, wie viel man testen kann: Bei Testgetriebener Entwicklung (TDD) erzeugt man ca. doppelt so viel Testcode, wie Produktivcode.
• Wenn wir schon bei TDD sind, der Hinweis: TDD ist genau genommen eine Design-Methode, die so „nebenbei“ auch umfangreiche Tests erzeugt. Ich hab das lange Zeit nicht verstanden. So langsam komm ich aber dahinter. Und es scheint tatsächlich Sinn zu machen.
• Auch, wenn TDD manchmal „Test-First“ genannt wird, würde ich das nochmal unterscheiden. Man kann die Tests zuerst schreiben, ohne, dass die Tests das Design treiben. Für mich macht das „fake it till you make it“ den Unterschied. Und das ist das, was erstmal sehr ungewohnt ist und das, was ich erst jetzt so langsam verstehe.