Verzicht auf Unit-Tests aus Kostengründen – Sparen muss man sich leisten können

Ich bin seit über elf Jahren Softwareentwickler (vorwiegend im Java-Umfeld) und doch erlebe ich es auch heutzutage noch - wie auch gerade aktuell wieder in einem Kundenprojekt -, dass es Projekte gibt, die Anwendungen entwickeln ohne Unit-Tests zu schreiben. Ich bin nach anderthalb Jahren in dieses laufende Projekt gestoßen. Auf die Frage, warum auf Unit-Tests und eine Continuous-Integration-Umgebung (CI-Umgebung) verzichtet wurde, bekam ich die Antwort: „Wir sparen Zeit und die Hardware für den CI Server!“

Als Anfänger in meinen ersten Projekten erkannte ich sehr schnell aus eigener (manchmal auch leidvoller) Erfahrung, wie sinnvoll und nützlich es ist, effiziente Unit-Tests zu schreiben. Es ist die kostengünstigste und einfachste Variante, Programm-Code zu testen, da ich kleine Teile des Codes isoliert auf die geforderte Funktionalität testen kann. In der Regel erfolgt das Testen auf Methodenebene. In Veröffentlichungen zum Thema Softwareentwicklung wird immer wieder auf die Wichtigkeit dieses Themas hingewiesen. So findet sich z. B. auf Martin Fowlers Seite ein Artikel zu diesem Thema.

Es gibt durchaus einige Personen, die „relativ“ fehlerfrei (ohne Unit-Tests) programmieren können und auch sehr schnell Probleme erkennen. Ich habe bisher aber nur sehr wenige davon getroffen und gehöre leider auch nicht zu diesen. Daher schreibe ich mit Vergnügen Unit-Tests in Verbindung mit Mock-Frameworks (z. B. Mockito), um „meinen“ Source Code zu testen. Wenn man diese Tests dann in Regression ausführt, bekommen die Entwickler, bei entsprechender Testabdeckung und aufgrund von nicht mehr funktionierende Tests, Seiteneffekte mit, die durch spätere Änderungen oder Erweiterungen auftreten. Nur so sind Anpassungen schnell und kostengünstig möglich, da auf manuelles (nachträgliches) Testen weitgehend verzichtet werden kann. So wird auch die Basis geschaffen, dass Änderungen nicht nur von einer Person, sondern grundsätzlich vom gesamten Team transparent vorgenommen werden können.

In meinem aktuellen Projekt habe ich all dies nicht vorgefunden, so dass wir nun vermehrt mit Produktionsfehlern zu tun haben und Änderungen sich schwierig gestalten. Dies führt auch zu einem signifikanten Mehraufwand und Verzögerungen bei Änderungen und Anpassungen.

Kurz gefasst sind Unit-Tests ein kostengünstiges Mittel, die Softwarequalität sowohl kurzfristig als auch langfristig zu erhöhen (Stichwort Wartbarkeit der Software). Darüber hinaus ist das Vorhandensein von Unit-Tests die Voraussetzung dafür, dass die im Laufe des Lebens einer Software erforderlichen Refactorings schnell und sicher durchgeführt werden können.

Bei Consist Software Solutions legen wir bei „unseren“ Projekten großen Wert auf dieses Thema und haben für uns entsprechende Qualitätskriterien ausgearbeitet. Ein Schwerpunkt ist der Einsatz von Unit-Tests als Regressionstests für die dauerhafte Qualitätssicherung.  

Im aktuellen Kundenprojekt habe ich dennoch Unit-Tests geschrieben, für meinen Code im Projekt, um zumindest dessen Funktionalitäten abzusichern.

Lesenswerte Bücher zum Thema Unit Testing:

[1] Unit Testing Principles, Practices, and Patterns; Vladimir Khorikov; Manning Publications

[2] The Art of Unit Testing; 2^nd Edition; Roy Osherove; Manning Publications