It is exciting for me to learn a new programming language, since it provides me with the opportunity to solve common programming problems more efficiently. In my primary area of work, back office business applications, Domain Driven Design (DDD) is widely used. So, when I switched from Java to Kotlin, I was curious to see how my new main language applies to these patterns . My first step was to learn about implementation alternatives of value objects, a concept for modelling data in DDD.

In learning about event storming, the hardest part for me was memorizing the order in which the different card types appear along the time line. As a result, I usually carried a cheat sheet like this with me.

I was bothered by its logic, however. It took me a while to figure out what it was about. I was able to make sense of it only after following the design process step by step for the first time. I would like to share this experience with you in this article by looking at an online shop’s order process.

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.