Architecture Decision Records (ADRs) are not only a great way to keep track of the choices you make while evolving your product architecture. It also guides you and your team through the decision process when you face new architectural challenges.

Trotz aller Tests im Vorfeld lassen sich Fehler im Release einer neuen Softwareversion nicht immer vermeiden. Zum Glück werden sie meist schnell entdeckt und lassen sich durch ein einfaches “Fix Forward” beheben. Leider gibt es aber Fälle, bei denen die Fehleranalyse sehr aufwändig und gleichzeitig ihre Auswirkung auf die Nutzbarkeit des Produktes gravierend ist. Man denke nur an Memory Leaks oder Dead Locks, die nicht nur durch klassische Tests vorm Deployment schwer zu erkennen sind, sondern in der Regel auch eine zeitaufwändige Ursachenforschung erforderlich machen.

Um in solchen Fällen die Einschränkungen für den Nutzer gering zu halten, liegt es nah, einfach wieder auf die vorherige Softwareversion zurückzugehen. Doch was so einfach klingt, ist in der Praxis oft mit Schwierigkeiten verbunden. Es gilt einmal mehr: “Everything comes with a price tag.”

Softwareentwicklung ist nichts für Feiglinge! Als Entwickler wissen wir, was so alles schiefgehen kann in den Produkten, die wir bauen. Immer wieder gehen wir in der Entwicklung Kompromisse ein, sei es um Aufwände zu sparen oder aber schlichtweg, weil die technischen Mittel nicht ausreichen, um allen Anforderungen uneingeschränkt gerecht zu werden. Doch sind diese Schwachstellen unserer Software Architektur auch unseren Product Ownern bewusst? Schließlich sind sie es ja, die am Ende des Tages die damit verbundenen Risiken tragen müssen? Ein einfaches Risikomanagement in der Architekturarbeit kann hier die notwendige Transparenz schaffen.

Ist die Testpyramide falsch und sollten wir lieber mehr Integration als Unit Tests schreiben, wie die alternative Test Trophy es vorsieht? Zeit für einen genaueren Blick auf diese beiden Teststrategien.

Wir entwickeln immer umfangreichere und komplexere Software. Gleichzeitig müssen neue Anforderungen schnell evaluiert und integriert werden, ohne dass ungewünschte Nebeneffekte auftauchen oder Nacharbeiten notwendig werden. Glücklich, wer da eine aktuelle und genaue Dokumentation seiner Applikation zur Hand hat. Doch der Aufwand hierfür steht meist in keinem Verhältnis zum Nutzen. Das muss aber nicht unbedingt so sein! Wer ein paar simple Regeln befolgt, kann einfach seine Tests als Dokumentation nutzen.

Tests lassen sich hervorragend für die Dokumentation und Spezifikation von Software nutzen. Besonders beliebt hierfür sind BDD-Frameworks wie Cucumber, die allerdings zusätzliche Komplexität mit sich bringen. Eine leichtgewichtige Alternative bietet jedoch das JGiven-Framework, das sich auch gut in eine bestehende Codebasis integrieren lässt.

Unittests sind das Fundament einer jeden guten Teststrategie und verdienen daher bei der Entwicklung unsere besondere Aufmerksamkeit. Doch worauf kommt es an und was muss ich dafür tun? Ein paar wenige Prinzipien und Praktiken helfen schon, Effizienz und Effektivität zu steigern.

Katas eignen sich nicht nur dazu, seine TDD-Fertigkeiten zu trainieren. Man kann sie auch dazu nutzen, sich mit neuen Sprachen und Testframeworks auseinanderzusetzen. Genau das habe ich getan, als ich mir eine der Aufgaben aus dem diesjährigen Advent of Code vornahm. Statt der üblichen Kombination aus Java und Junit5 kamen diesmal Kotlin und KotlinTest zum Einsatz und ich bin, soviel sei hier schon verraten, begeistert. Schon beim ersten Versuch konnte ich meine Tests in einer Ausdrucksstärke schreiben, wie ich sie mit den bisherigen Frameworks, die ich verwendet habe, nie in der Lage war, zu erreichen.

Unser Job als Entwickler ist es, aus Ideen konkrete Softwareprodukte entstehen zu lassen; die Herausforderung dabei: Wir müssen unvollständige, unscharfe Anforderungen in eindeutige, exakte Implementierungen überführen. Keine leichte Aufgabe also, die wir da meistern müssen, und die Chance, das Ziel zu verfehlen oder wichtige Aspekte zu übersehen, ist riesig, wie genügend gescheiterte Projekte berichten können. Dabei gibt es einen ebenso einfachen wie effektiven Weg, diese Gefahren zu verringern: Test First!

Ein guter Weg um diesen Ansatz zu üben. Mehr dazu erfahrt Ihr hier.

Eignet sich die Messung der Testabdeckung zur Steuerung der Codequalität und damit der Produktivität im Unternehmen? Und wenn nicht, was kann man tun, um beides zu verbessern? Die Meinungen hierzu gehen weit auseinander. Es lohnt sich also, genauer hinzuschauen.