Anwendungen in einzelne Bestandteile zu zerlegen, gehört heute, aus unterschiedlichsten Gründen, zum guten Ton in der Anwendungsentwicklung. Aus welchem Grund betreiben wir diesen Aufwand? Um tatsächlich die Persistenzschicht morgen austauschen zu können? Oder nicht viel mehr deshalb, um unsere Anwendung besser testen zu können? Doch weichen wir diese Zerlegung nicht in vielen Tests wieder auf? Schreiben wir möglicherweise Tests welche Annahmen treffen, die gar nicht in dem zu vertestendem Bestandteil implementiert ist, sondern in einem Bestandteil welches unser SUT (System under Test) selbst nur nutzt? Die verschiedenen Bestandteile unserer Anwendung beinhalten unterschiedliche Risiken, welchen wir individuell begegnen sollten und zwar unabhängig davon, für welche Deploymentform (Monolith/Modulith, Microservice, Lambda) wir eine Anwendung bauen.

Der Vortrag soll aufzeigen, wie wir eine Anwendung so zerlegen können, dass wir Verhalten dort testen können, wo dieses implementiert ist. Dazu schauen wir auf eine kleine, überschaubare Beispielanwendung, welche auf den ersten Blick vielleicht nicht viel mit dem zu tun hat, was wir täglich bauen, aber eben nur auf den ersten.

Und das schöne ist: Wenn wir uns durch die Domäne und die Tests treiben lassen, entsteht die angesprochene Zerlegung fast automatisch bzw. es ist dabei schwer, gegen diese zu verstoßen.