Wahrscheinlich liegt es am einprägsamen Bild der Testpyramide: Projekte strotzen nur so von tausenden winziger Tests mit zweifelhafter Bedeutung, und die Software funktioniert trotzdem nicht. Das ist nicht verwunderlich, denn diese Minitests vernachlässigen die Kollaboration der Bestandteile, auf die es genauso ankommt. Wir werden nicht für einzelne Klassen bezahlt, sondern für Features und Usecases, und die gilt es primär zu testen. Also mal Umdenken: Testunits nicht so klein, sondern so groß wie möglich, Mockito und Selenium raus, Datenbank rein und konsequentes "Design for Test", wo es in der Architektur knifflig wird. Die Session zeigt Beispiele und Architekturmuster aus der Praxis, um das Konzept der "sociable Unittests" zu fördern, die auf ganze Usecases abzielen und eine andere Größenordnung von Absicherung schaffen.