Manche Softwareentwicklungsteams sind agiler als andere, aus den unterschiedlichsten Gründen. Bei meiner Arbeit mit zahlreichen Teams habe ich während der letzten Dekade ein wiederkehrendes Muster beobachtet: Teams mit guter, schneller Testautomatisierung liefern oftmals bessere Lösungen kontinuierlicher ab – und besitzen dabei auch noch einen besseren Team-Spirit. Aber warum erreiche manche Teams eine gute Testautomatisierung, während sich andere damit über Jahre abmühen?

Meiner Erfahrung nach hängt dies davon ab, ob der Code einfach testbar ist. Oft denkt man dann sofort an Programmierpraktiken wie Test-Driven Development (TDD), durch die ein besseres – besser testbares! – Code-Design entsteht. Aber es gibt auch einige Architekturstile bzw. -muster, die ein einfacheres Testen mit schnelleren Feedback-Schleifen ermöglichen.

Wir schauen uns in dieser Session an, was es bedeutet, Geschäftslogik von Integrationscode zu trennen, welche unterschiedlichen Code-Designs und Architekturmuster es gibt, um dieses Ziel zu erreichen – und warum damit kleinere und schnellere automatisierte Tests möglich sind.

Es geht dabei um die absoluten Grundlagen von testbarem Code und testbarer Architektur. Wer sich nicht täglich mit diesen Themen beschäftigt, wird Anregungen und Tipps bekommen, wie man sofort morgen im eigenen Projekt die ersten Verbesserungen vornehmen kann. Die Session wird eine ausgewogene Mischung sein aus Folien und Live-Coding.