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.

Wenn wir programmieren, müssen wir ständig viele Aspekte gleichzeitig im Blick behalten. Da sind zum einen die fachlichen Anforderungen, dann die Details der eingesetzten Technologien und schließlich soll der Code auch noch gut wartbar und erweiterbar sein. Wie schaffen wir es, dem gerecht zu werden, ohne dass uns irgendetwas durchrutscht? Wieder einmal ist es die Testgetriebene Entwicklung, die uns hierauf eine Antwort liefert, indem sie uns dabei hilft, den Überblick zu bewahren und nicht im Multitasking unterzugehen.

Kaum ein Entwicklungsteam ist mit seiner Dokumentation glücklich. Oft fehlen dringend benötigte Informationen, können nicht gefunden werden oder sind einfach hoffnungslos veraltet. Dabei wird meistens nicht zu wenig, sondern nur zu ineffizient dokumentiert. Ein Workshop kann Euch dabei helfen, eine gute Dokumentationsstrategie zu finden. Getreu dem agilen Prinzip: “Maximiere die Arbeit, die Du nicht tust.”

Wenn wir Software entwickeln, ist es unser Ziel, regelmäßig ein Produkt zu liefern, dass alle Anforderungen erfüllt. Um das auch nachzuweisen zu können, bräuchten wir eine Rückverfolgbarkeit zwischen den Quellen einer Anforderung und unseren Liefergegenständen, und zwar in beide Richtungen. Ein weit verbreitetes Werkzeug hierfür ist die Traceability Matrix, die jedoch meist mit einem hohen Pflegeaufwand verknüpft ist, zumindest, wenn man eine einigermaßen hohe Aktualität und Korrektheit erreichen möchte. Die Testgetriebe Entwicklung in Verbindung mit dem Continuous-Integration-Ansatz bietet uns hier eine schlanke und gleichzeitig validierbare Alternative.

Entwickeln, Testen, Betreiben. Das ist das uralte Mantra der Softwareentwicklung. Wir haben es so oft wiederholt und verinnerlicht, dass wir uns selbst in einem agilen Umfeld nur schwer davon lösen können. Die Tester sind zwar nun Teil des Entwicklungsteams und am Ende eines jeden Sprints testen diese auch regelmäßig das Produktinkrement, aber nach wie vor findet die Qualitätssicherung fast ausschließlich zwischen der Entwicklung und dem Betrieb statt. Doch wir können noch weitaus mehr von der interdisziplären Ausrichtung agiler Teams profitieren, wenn wir unsere Testaktivitäten aus diesem Silo befreien und sie sowohl in die Entwicklung als auch in den Betrieb verlagern.

Wenn wir ein neues Feature testgetrieben entwickeln, stellt sich als erstes immer die Frage, mit welchen Test wir am besten starten. In Coding Dojos habe ich beobachtet, dass die Teilnehmer meist mit dem ersten Testfall beginnen, der ihnen in den Sinn kommt. Aber ist das auch der beste Einstieg, von dem aus sich die folgenden TDD-Iterationen einfach aufbauen lassen und schließlich zur gewünschten Implementierung führen? Um diese Frage zu beantworten und einen guten Implementierungspfad zu finden, kann eine Testliste sehr hilfreich sein.

Es gibt wohl wenige Frameworks, die eine testgetriebene Vorgehensweise so gut unterstützen wie Spring Boot. Dem Entwickler bieten sich eine ganze Reihe verschiedener Testwerkzeuge und -strategien, aus denen er sich bedienen kann. Doch wie kann ich diese am effektivsten und effizientesten im Rahmen eines TDD-Ansatzes einsetzen? Über die Jahre haben sich bei mir einige Grundprinzipien herauskristallisiert, die ich gerne mit Euch teilen möchte.

Agile Transformationen nehmen ihren Anfang meist in der Entwicklungsabteilung eines Unternehmens. So auch im Fall der Thalia eCommerce IT, deren Wandel zu einer agilen Produktorganisation mit selbstorganisierten Teams ich als Coach unterstützen durfte. Dass diese Veränderung jedoch auch massive Auswirkungen auf die Betriebsabteilung im Unternehmen mit sich bringt, wurde mir erst so recht bewusst, als ich mit deren Leiter im Rahmen einer Schulung zum Thema “Agiles Mindset” ins Gespräch kam. Dank meiner Operationsvergangenheit entwickelte sich schnell die Idee, dass ich ihn und sein Team bei der Reise in die schöne, neue, agile Welt begleite. Die Erfahrungen, die wir dabei gemacht haben, habe ich nun in einem Blogpost zusammengefasst.