Es gibt diesen einen Test. Diesen Test, der die Story - genauer: das Szenario - in die Sprache der Applikation übersetzt. Und ich suche nach einem Namen. Wenn die Story mit den Szenarien die Akzeptanzkriterien ausdrückt. Und wenn ein Akzeptanztest diese Kriterien in die Sprache der Applikation übersetzen, dann handelt es sich bei diesem einen Test, um den der den Akzeptanztest als Unittest implementiert.
Akzeptanztests können auf ganz unterschiedliche Weise implementiert sein. Es mag sich um Test mit Hilfe eines Akzeptanztest-Frameworks handeln, wie bspw. Fitness, Fit oder Cucumber. Es mag sich um einen Test handeln, der über das Userinterface auf die Anwendung zugreift, wie bspw. Seleniumtests die Webschnittstelle adressieren. Oder es kann sich um Akzeptanztests handeln, die ein Unittestframework nutzen um ausgedrückt zu werden. In jedem dieser Fälle ist es wichtig, dass der Test die gesamte Anwendung testet, dass der Test anzeigt, ob die Funktionalität in der angezielten Weise implementiert ist oder nicht.
Unittest übernehmen eine andere Aufgabe. Sie zeigen auf, dass diese Klasse oder diese Gruppe von eng kollaborierenden Klassen eine bestimmte Funktion erfüllt. Um den gleichen Umfang wie der Akzeptanztest abzudecken, ist eine ganze Kette von Unittests notwendig. Und unter diesen ist der oberste, derjenige der die Story in die Sprache der Applikation (eben auch in die Programmiersprache) übersetzt, der erste unter gleichen - primus inter pares.
Wenn die Akzeptanztests in der Sprache der Anwendung geschrieben sind, ist der Unittest in gewissem Sinne mit dem Akzeptanztest identisch. Sein Setup ist ein anderes, er legt Wert darauf die Funktionalität an einer Klasse in Isolation zu testen, aber die Schnittstelle, die er benutzt, sollte die gleiche sein. [Wenn das nicht so ist, weil die Story bspw. gar keinen spezifischen Ort in der Applikation hat, ließe sich von einem Code Smell sprechen. Aber das - der Ort einer Story in der Applikation (UseCaseController, Manager, anämisches Objektmodell) - ist Thema für eine andere Gelegenheit.]
Die Rolle des Ersten unter den Unittests ist in unserem Coding-Dojo aufgetaucht. Immer wenn wir diesen Test nicht hatten, verloren sich Entwicklungen in tieferen Schichten der Applikation im Spekulativen, wenn er da war, gab er den anderen eine Richtung vor. Wir haben das zunächst als Primat des Top-Down-Ansatzes verhandelt. Erst mit dem Gedanken des Top-Down-Ansatzes wurde im Dojo explizit, dass es sich besser anfühlt, wenn man die Frage beantwortet hat, welches ist die zentrale Einstiegsfunktion für die Story und wie sehen die Tests für diesen Einstiegspunkt aus. Aber - und deshalb wiederstrebt es mir hier von einem Top-Down-Ansatz zu sprechen - wenn der oberste Unittest erst einmal gefunden ist, ist es auch möglich in unteren Schichten der Applikation zu beginnen, ohne sich zu verlieren. Der oberste Unittest gibt der Implementierung eine Richtung, auch wenn diese syntaktische und programmatisch noch nicht in allen Ebenen und Schichten explizit ist. In einer anderen Sprache und einem anderen Land könnte man vielleicht von Führung und einem führenden Test sprechen, aber bei uns?