Test First ist keine Teststrategie, sondern eine Designstrategie. Es ist eine Frage der Priorisierung: das der Produktionscode durch den Testcode getestet wird, ist niedriger anzusiedeln als der Umstand, dass das Design des Codes deutlich an Qualität gewinnt. Grund für letzteres ist, dass der Entwickler den Produktionscode bereits benutzt, bevor er ihn niederschreibt. Er muss zuerst darüber nachdenken, wie die Schnittstelle gestaltet sein soll, welche Objekte er miteinander interagieren lassen möchte und natürlich auch, wie er den Code testen kann. Ohne Test First entstehen Schnittstellen, die nur schwer und umständlich benutzbar sind, Objekte, die nicht miteinander interagieren oder aber nur mit viel Aufwand, und sogar untestbarer Code ist häufig die Folge.

Test First erfordert ein enormes Umdenken bezogen auf die klassiche Herangehensweise, das Schreiben von Tests nach dem Implementieren des Codes. Besonders vor dem Handeln über die Konsequenzen nachdenken zu müssen, scheint vielen an diese Technik ungewöhnten schwer zu fallen. Dabei vergessen Neulinge häufig, dass es sich um jederzeit änderbaren Code handelt, so dass ihre Entscheidungen wieder aufhebbar sind, wenn sie sich als ungeeignet herausstellen sollten.

Eine entsprechende IDE kann und sollte Test First unterstützen. So kann sie nicht vorhandene Variablen, Methoden, Klassen und Interfaces per Knopfdruck an der richtigen Stelle erzeugen. Auch GnadenlosesRefaktorisieren sollte sie beherrschen, ist diese Technik doch auch enorm wichtig für das Schreiben von Tests im Allgemeinen und Test First im speziellen.

Test First bezieht sich auf alle Arten von Tests, also sowohl auf AkzeptanzTests, als auch auf UnitTests. Auch Systemtests, Integrationstests und sonstige Testarten können jeweils vor dem Produktionscode erzeugt werden.

Ein Ziel beim Einsatz dieser Technik könnte die EinhundertProzentTestabdeckung sein. Hilfreich hierfür ist es allemal.