Wir alle kennen das: am Anfang eines Softwareentwicklungsprojektes macht man sich Gedanken über Architektur, Bausteine, Abhängigkeiten und solche Dinge. Dann läuft man los und implementiert. Anfangs ist die Produktivität hoch. Doch der Code wird immer mehr und die Anforderungen werden komplexer. Es schleichen sich ungewollte Abhängigkeiten ein. Eine Referenz ist nun mal in modernen Entwicklungsumgebungen schnell hinzugefügt. Im Laufe der Zeit weicht man ohne es zu merken immer weiter von der ursprünglich entworfenen Architektur ab. Architekturdiagramme und Code passen nicht mehr zusammen. Das lässt sich auch mit Clean Code, Test-driven Development und regelmäßigen Architekturreviews nicht immer verhindern.

Eine Möglichkeit, dem entgegenzuwirken, sind Architekturtests. Die funktionieren wie Unit Tests, testen aber keine funktionalen Anforderungen, sondern nichtfunktionale bzw. Qualitätsanforderungen. Tools sind als Open Source für Java und .NET verfügbar. Der Einstieg ist leicht. Architekturtests können automatisiert im Continuous Build laufen und verhindern dadurch, dass sich Verstöße gegen die anfangs aufgestellten Architekturregeln einschleichen.

Dieser Vortrag gibt einen Überblick darüber, was mit Architekturtests alles möglich ist. Anhand einer Beispielarchitektur, die an das taktische Design aus dem Domain-Driven Design angelehnt ist, wird demonstiert, wie sich verschiedene Aspekte der Architektur testen lassen.