Die 10 goldenen Regeln für schlechte Tests

Es ist eine schöne Illusion: Mühsam hat man sich eine ganze Suite an automatisierten Unit-, Komponenten- und Integrationstests aufgebaut. Man hat sich ein Sicherheitsnetz aufgebaut. Das gibt ein gutes Gefühl. Zumindest so lange alle Tests „grün“ sind. Leider holt uns die Realität häufg bald auf verschiedene Arten wieder ein:

• Ein Test wird rot und niemand weiß warum. Selbst bei intensiver Betrachtung ist noch nicht einmal klar, was der Test eigentlich sicherstellen sollte.
• Ein kleines Refactoring macht auf einen Schlag mehrere hundert Tests unbrauchbar
• Tests schlagen nicht an, obwohl die Funktionalität, die sie absichern sollten bricht
• Tests bestehen aus Mocks, die Mocks aufrufen, die Mocks konfigurieren und am Ende steht eine Assertion, die eigentlich nur prüft, ob wir unseren Mock richtig konfiguriert haben
• Usw.

Oft steht man dann vor der Entscheidung: Intensiv forschen, Test wegwerfen, oder hoffen, dass er sich von selbst wieder löst. Dabei haben wir es doch nur gut gemeint, als wir die Tests geschrieben haben.

Bei unserer täglichen Arbeit in Softwareprojekten und bei unserer Tätigkeit als Coaches für Agiles Software Engineering haben wir immer wieder schmerzhaft erfahren, dass „gut gemeint“ das Gegenteil von „gut“ ist. Dass man sich im Sicherheitsnetz schmerzhaft verfangen kann und das Netz zerschneiden muss. Wir haben unsere Schlüsse daraus gezogen.

Im Vortrag wollen wir die unserer Meinung nach wesentlichsten Antipatterns für automatisierte Tests vorstellen. Außerdem zeigen wir Wege auf, wie man in den meisten Fällen mit ganz einfachen Mitteln stabile, aussagekräftige Tests schreiben kann, die nachhaltig unsere Produkte schützen.