In den Zeiten von DDD und BizDevOpsSec-crossfunktionalen Teams haben wir optimalerweise das notwendige Know-how und setzen die entsprechenden Integrationstests des ganzen Microservices-Konglomerates in dem jeweiligen Scrum-Team um. Diese Tests sind oft in einem separaten Test-Framework, im Gegensatz zu den getesteten Microservices, monolithisch implementiert. An sich eine gute Sache. Der Tester kümmert sich selbst um die Tests und testet die komplette Domäne. Doch wie steht es dabei mit der Transparenz und der Vertretung? Oder können wir in dieser Situation auch mit dem Test-driven-Development-Ansatz arbeiten? In diesem Vortrag stellen wir einen anderen Ansatz der Struktur der Integrationstests vor. Mit Behaviour-driven Development (BDD) und dem Framework Cucumber als Grundlage empfehlen wir eine modulare Architektur der Testprojekte, angelehnt an die Microservices-Architektur selbst. Wir zeigen in einer Demo, wie dabei trotz verteilter Implementierung der Test-Steps auch Integrationstests über mehrere Module hinweg umgesetzt werden können. Als Abschluss werden wir Vor- und Nachteile beider Ansätze vergleichen.