Die Klassen beziehungsweise Objekte einer Software stellen die Bausteine dar, aus denen die Funktionalität der Anwendung zusammengesetzt wird. Durch ein ausreichendes Maß an Unit-Tests kann man sicherstellen, dass sich die einzelnen Bausteine wie erwartet verhalten. Mit Systemtests betrachtet man die gesamte Anwendung als eine Einheit, ohne sich damit zu befassen, aus welchen Bausteinen das System im Einzelnen besteht und wie diese interagieren.
Integrationstests schließen die Lücke zwischen diesen beiden Testkonzepten, indem sie auf die Schnittstellen zwischen Komponenten fokussieren und sicherstellen, dass ihr Zusammenspiel wie erwartet funktioniert. Sie stellen den in der Praxis vielleicht wichtigsten Baustein im Testkonzept dar, denn Systemtests sind zu groß, um eine hinreichend genaue Aussage über die Quelle eines Fehlers zu machen. Unit-Tests dagegen sind zu klein, um eine verwertbare Aussage über das Verhalten der gesamten Anwendung zu machen.
Hinzu kommt, dass Systemtests eine komplexe Test-Umgebung und viele Systemressourcen zur Ausführung benötigen. Sie sind damit zu langsam und zu teuer, um als Fundament einer Teststrategie zu dienen. Wir kennen Unternehmen, in denen die Ausführung aller Systemtests mehrere Stunden dauerte. Für ein zeitnahes Feedback besonders über diejenigen Fehler, die im Rahmen der Pflege oder Weiterentwicklung gerade neu eingeführt wurden, werden Tests in einem kleineren Wirkungsbereich benötigt. Nur diese helfen den Entwicklern dabei, aufgetretene Fehler unmittelbar den kürzlich vorgenommenen Änderungen zuzuordnen. Dauert es zu lange, bis das Feedback beim Entwickler eintrifft, ist Testen im Sinne agiler Software-Entwicklung nicht mehr möglich.
Integrationstests stellen sicher, dass mehrere Code-Einheiten, deren korrektes Verhalten in Isolation voneinander bereits durch Unit-Tests sichergestellt wurde, wie erwartet zusammenarbeiten. Testet man dabei von einer System- oder Komponentengrenze bis zu einer anderen solchen Grenze, spricht man von Edge-to-Edge-Tests. Aufbauend auf den Ergebnissen der Integrationstests stellt man mit End-to-End-Systemtests in Form von Akzeptanztests sicher, dass das System sich so verhält, wie es der Auftraggeber erwartet.
Beim Behaviour-Driven Development (BDD), dem in den letzten Jahren einige Aufmerksamkeit zuteil geworden ist, werden Akzeptanztests in der so genannten allgegenwärtigen Sprache (ubiquitous language) spezifiziert. Diese ist eine gemeinsame Sprache aller am Projekt beteiligten Parteien. Die einzelnen Bestandteile der Akzeptanzkriterien werden beim BDD von einem Parser auf Methodenaufrufe in einer Testklasse abgebildet. Im Gegensatz zur testgetriebenen Entwicklung, die den Fokus auf den Zustand von Objekten legt, rückt beim Behaviour Driven Development das Verhalten der Anwendung in den Mittelpunkt.
Es gibt allerdings keinen technischen Grund dafür, Akzeptanztests ausschließlich als End-to-End-Tests durch die Bedienoberfläche durchzuführen. Viele Geschäftsregeln wie beispielsweise Plausibilitätsprüfungen können ohne große Probleme in einer wesentlich kleineren Testumgebung getestet werden. Durch eine sinnvolle Organisation und sprechende Namen von Testklassen und -methoden können auch klassische Unit-Tests für nicht-technisches Personal hinreichend lesbar und verständlich sein, beispielsweise indem mit Testdox Dokumentation direkt aus dem Testcode erzeugt wird.
Erlaubt es die Architektur der Software, dass sowohl kleine Unit-Tests als auch mittelgroße Edge-to-Edge-Tests ohne großen Aufwand realisierbar sind, dann steht dem Einsatz von Experiment-Driven Development oder Testing in Production nichts mehr im Wege. Bei diesen neuen Ansätzen, die unter anderem auf Ideen von Eric Ries basieren, wird ein neues Feature zunächst als Experiment implementiert, das – möglicherweise nur für eine Untermenge der Nutzer einer Webanwendung – in Produktion auf seinen Geschäftswert getestet wird. Möglicherweise wird ein Feature sogar erst dann so implementiert, dass es den Qualitätszielen wie beispielsweise Performanz, Skalierbarkeit oder Wartbarkeit genügt, wenn es seinen Geschäftswert bewiesen hat. Die Entscheidung erfolgt mithilfe von statistischen Methoden auf Daten und Metriken, die in Produktion gesammelt werden.
Allein die Aussicht, sowohl das Geschäftsmodell als auch die Software agil und durch Experimente getrieben weiterentwickeln zu können, dürfte für viele Unternehmen schon Grund genug sein, auf eine moderne, stark entkoppelte Anwendungsarchitektur zu setzen. Mit ein wenig technischer Infrastruktur, die für die notwendige Flexibilität beim Erzeugen und Verdrahten der einzelnen Objekte sorgt, sind Experimente im Livebetrieb nämlich nahezu ohne zusätzlichen Aufwand möglich.