Ein Test Double ist eine testspezifische Funktion, die eine Systemfähigkeit ersetzt, in der Regel eine Klasse oder Funktion, von der die UUT abhängt. Es gibt zwei Male, in denen Testdoubles in ein System eingeführt werden können: Link und Ausführung. Die Verknüpfungszeitersetzung erfolgt, wenn das Testdouble in das Lastmodul kompiliert wird, das zum Überprüfen von Tests ausgeführt wird. Dieser Ansatz wird in der Regel verwendet, wenn er in einer anderen Umgebung als der Zielumgebung ausgeführt wird, die für die Kompilierung des Hardware-Levelcodes verdoppelt werden muss. Die Alternative zur Linkersubstitution ist die Laufzeitersetzung, bei der die reale Funktionalität während der Ausführung eines Testfalls ersetzt wird. Diese Ersetzung erfolgt in der Regel durch neuzuweisung bekannter Funktionszeiger oder Objektersetzung. BDD (behavior-driven development) kombiniert Praktiken von TDD und ATDD. [27] Es umfasst die Praxis, zuerst Tests zu schreiben, konzentriert sich jedoch auf Tests, die das Verhalten beschreiben, und nicht auf Tests, die eine Implementierungseinheit testen. Tools wie JBehave, Cucumber, Mspec und Specflow bieten Syntaxen, die es Produktbesitzern, Entwicklern und Testingenieuren ermöglichen, gemeinsam die Verhaltensweisen zu definieren, die dann in automatisierte Tests übersetzt werden können. Die testgesteuerte Entwicklung ist mit der Akzeptanztest-gesteuerten Entwicklung (ATDD) verbunden, unterscheidet sich jedoch von dieser. [26] TDD ist in erster Linie ein Entwicklertool, mit dem gut geschriebene Codeeinheiten (Funktion, Klasse oder Modul) erstellt werden können, die eine Reihe von Vorgängen korrekt ausführt. ATDD ist ein Kommunikationstool zwischen Kunde, Entwickler und Tester, um sicherzustellen, dass die Anforderungen genau definiert sind. TDD erfordert Testautomatisierung.

ATDD nicht, obwohl die Automatisierung bei Regressionstests hilft. Tests, die in TDD verwendet werden, können häufig aus ATDD-Tests abgeleitet werden, da die Codeeinheiten einen Teil einer Anforderung implementieren. ATDD-Tests sollten vom Kunden lesbar sein. TDD-Tests müssen nicht sein. Leider werden wir mit unserem bestehenden Setup bestehende Verbraucher brechen, wenn wir eine erforderliche Komponente – in diesem Fall das Feld InStock – aus unserem erweiterbaren Schema entfernen. Um den Anbieter zu beheben, müssen wir das gesamte System reparieren: Wenn wir die Funktionalität aus dem Anbieter entfernen und einen neuen Vertrag veröffentlichen, muss jede Consumer-Anwendung mit dem neuen Schema erneut bereitgestellt und die Interaktionen zwischen Diensten gründlich getestet werden. Der ProductSearch-Service kann sich in dieser Hinsicht nicht unabhängig von seinen Verbrauchern entwickeln: Anbieter und Verbraucher müssen alle gleichzeitig springen. Komponententests sind so benannt, weil sie jeweils eine Codeeinheit testen. Ein komplexes Modul kann über tausend Komponententests und ein einfaches Modul nur zehn haben. Die für TDD verwendeten Komponententests sollten niemals Prozessgrenzen in einem Programm überschreiten, geschweige denn Netzwerkverbindungen. Dadurch werden Verzögerungen eingeführt, die dazu führen, dass Tests langsam ausgeführt werden und Entwickler davon abgehalten werden, die gesamte Suite auszuführen. Durch die Einführung von Abhängigkeiten von externen Modulen oder Daten werden Komponententests auch zu Integrationstests.

Wenn sich ein Modul in einer Kette miteinander verbundener Module falsch verhält, ist nicht so schnell klar, wo nach der Ursache des Fehlers gesucht werden soll. Komplexe Systeme erfordern eine Architektur, die eine Reihe von Anforderungen erfüllt. Eine wichtige Teilmenge dieser Anforderungen umfasst die Unterstützung für die vollständige und effektive Prüfung des Systems. Effektives modulares Design liefert Komponenten, die Eigenschaften teilen, die für eine effektive TDD unerlässlich sind. Eine Studie aus dem Jahr 2005 fand heraus, dass die Verwendung von TDD bedeutete, mehr Tests zu schreiben, und im Gegenzug neigten Programmierer, die mehr Tests schrieben, dazu, produktiver zu sein. [12] Hypothesen zur Codequalität und eine direktere Korrelation zwischen TDD und Produktivität waren nicht schlüssig. [13] Ungeachtet solcher Zwänge wird der Umfang eines Vertrags lediglich durch den Zusammenhalt seiner Mitgliedselemente bestimmt.