Automatisierte Tests
Zu den Vorteilen von automatisierten Tests muss man sicherlich nicht allzu viele Wörter verlieren.
Bei uns ist der durch Tests abgefangene potentielle Schaden durch die in vorhergehenden Abschnitten beschriebene Projektlandschaft deutlich höher, als wenn wir nur ein zentrales Mono-Repo hätten. Genauso wie ein Bug, der erst im Produktiv-Betrieb und nicht schon während der Entwicklung gefunden wird, höhere Aufwände und damit Kosten verursacht, gilt das auch für einen Fehler, der erst in einem abhängigen Projekt (bspw. im Kundenprojekt) gefunden wird, aber seine Entstehung in einer zugrundeliegenden internen Bibliothek hat. So gesehen profitieren wir von jedem Test, der Bugs an Ort und Stelle abfängt, mehrfach.
Trotzdem sind wir hier nicht dogmatisch. Eine einhunderprozentige Code-Abdeckung und ein Test-First-Dogma birgt Vorteile, doch es bringt in Anbetracht von sich häufig ändernden Anforderungen natürlich auch entsprechenden Aufwand mich sich, der im wirtschaftlich-zeitlichen Rahmen abgebildet werden muss. Derzeit verwenden wir daher eher Integration-Tests für den erwarteten Pfad durch den Code sowie einige Sonderfälle und fangen so den Großteil der Fehler ab.
Die Tests begleiten uns bereits während der Entwicklung. Sie werden aber auch im Rahmen des Build-Prozesses durch unsere Pipelines permanent ausgeführt. Damit stellen wir sicher, dass uns eine Pipeline auch dann auffängt, wenn man bspw. mal vergessen hat, sich an die Konvention zu halten, oder wenn es zu einer unvorhergesehenen Regression kommt.
Außerdem arbeiten wir mit Code-Reviews und Mentoring an einem hohen Standard für Code-Design. Viele Fehler entstehen überhaupt erst dadurch, dass Entwickler gar nicht genau verstehen, was die Kollegen (oder man selber vor wenigen Wochen) vorher implementiert haben. Mit entsprechenden Stil-Mitteln kann Quellcode les- und formbarer machen. Es ist uns wichtig, uns und unsere Arbeit durch entsprechendes Refactoring kontinuierlich zu verbessern.