Gastbeitrag: ATDD kurz erklärt – Die richtigen Dinge entwickeln

Gastbeitrag: Ralf Wirdemann www.b-simple.de

Akzeptanztest-getriebene Entwicklung (kurz ATDD, für Acceptance Test Driven Development) ist eine Entwicklungspraxis, in der die funktionalen Anforderungen einer User Story als konkrete und automatisierbare Beispiele vor der eigentlichen Entwicklung der Story selber geschrieben werden. ATDD fördert die Kommunikation zwischen Product Owner und Entwicklungsteam und hilft Software zu entwickeln, die der Kunde wirklich will. ATDD treibt die Entwicklung einer User Story entlang ihrer Akzeptanzkriterien. Akzeptanzkriterien beschreiben Geschäftsregeln, die erfüllt sein müssen, damit die Story als fertig gilt und vom Product Owner abgenommen wird. Betrachten wir als Beispiel eine User Story für die Durchführung einer Banküberweisung:

Als Kunde will ich einen Betrag von meinem Konto auf ein Zielkonto überweisen.

Der Product Owner schreibt einige einfache Akzeptanzkriterien für die Story:

• Das Quellkonto wird um den überwiesenen Betrag reduziert
• Das Zielkonto wird um den überwiesenen Betrag erhöht
• Die Überweisung muss durch eine gültige TAN legitimiert werden
• Der Kunde muss angemeldet sein
• …

Während der Titel einer User Story relativ vage ist, sind ihre Akzeptanzkriterien sehr viel konkreter. Sie definieren die Kerngeschäftsregeln der Story in der Sprache der Anwendungsdomäne und machen die Story gleichermaßen verständlich und verbindlich. Akzeptanzkriterien erweitern eine User Story um messbare Aspekte und legen genau fest, wann die Story fertig im Sinne der Definition of Done ist.

Neben der Forderung, Akzeptanzkriterien für jede User Story zu schreiben, verlangt ATDD vom Product Owner praxisrelevante Beispiele. Ein Beispiel für das erste Akzeptanzkriterium der Überweisungs-Story könnte wie folgt aussehen:

Wenn ich bei einem Kontostand von 100 EUR 20 EUR auf ein anderes Konto überweise, dann reduziert sich mein Kontostand auf 80 Euro.

Das Beispiel ist ein Test für die erste Geschäftsregel der Story: Der Kontostand wird reduziert. Jeder Kunde oder Entwickler, der diesen Test liest, versteht, was die Story leistet. Und genau dies ist der eigentliche Wert von ATDD: Das Schreiben von erklärenden Beispielen für die Geschäftsregeln der User Story, so dass jeder die Story versteht. Die Erstellung von Akzeptanzkriterien inklusive der zugehörigen Tests, ausgedrückt als Beispiele aus der Praxis, ist ein  hervorragendes Werkzeug, um ein gemeinsames Verständnis für die Anforderungen zu entwickeln. Kunden und Teams werden gezwungen, miteinander zu reden, und entwickeln eine gemeinsame Sprache der Anwendungsdomäne. Das Schreiben von beispielhaften Tests ist nur ein Schritt des Akzeptanztest-getriebenen Entwicklungsprozesses. Der nächste Schritt ist die Automatisierung der Tests. Automatisierte Testläufe können per Klick und ohne weitere Benutzerinteraktion ausgeführt werden. Die Tests validieren Geschäftsregeln und sind grün, wenn alles wie erwartet funktioniert. Dieser Ansatz ist ähnlich dem der Testgetriebenen Entwicklung (TDD): Erst wird ein fehlschlagender Akzeptanztest geschrieben, und anschliessend wird gerade genug Funktionalität implementiert, dass der Test erfolgreich ausgeführt werden kann.

Nehmen wir das obige Beispiel und versuchen einen einfachen Akzeptanztest zu schreiben:

public void shouldReduceSourceAccount() {
givenAnAccountWith100Euro();
whenCustomerTransfers20Euro();
thenSourceAccountBalanceShouldBe80Euro();
private void givenAnAccountWith100Euro() {
this.customer = BigBank.login("ralf", "sword");
this.customer.account.setBalance(100);
BigBank.updateAccount(account);
private void whenCustomerTransfers20Euro() {
BigBank.transferMoney(this.customer.account, destAccount, 20);
private void thenSourceAccountBalanceShouldBe80Euro() {
Assert.assertEquals(80, this.customer.account.getBalance();

Der Test ist basierend auf der verbreiteten ATDD-Terminologie given/when/then. Der „given“-Teil formuliert die Voraussetzung für den Test. Der „when“-Teil beschreibt die Aktion zur Ausführung der getesteten Geschäftsregel. Und der „then“-Teil beschreibt das erwartete Ergebnis. Im Beispiel sehen wir, dass der Kontostand auf 80 Euro reduziert werden soll, nachdem die Überweisung durchgeführt wurde. Der interessante Teil des Tests ist die aufgerufene transferMoney-Methode, die die eigentliche Überweisungsfunktionalität implementiert. Wird der Test ohne gültige transferMoney-Implementierung ausgeführt, schlägt er fehl. Um ihn zum Laufen zu bringen, muss gerade so viel Funktionalität implementiert werden, dass der Kontostand auf 80 Euro reduziert
wird. ATDD ist damit eine Art TDD auf der Geschäftsebene.

Akzeptanzkriterien und die dazugehörigen Tests messen kontinuierlich den Entwicklungsfortschritt einer User Story. Wenn Sie ihrem Product Owner einen Knopf zum Ausführen der automatisierten Tests zur Verfügung stellen, dann ist er immer in der Lage, den aktuellen Stand der User Story abzufragen. Die Akzeptanzkriterien treiben die Entwicklung der User Story voran. Es wird kein neuer Code implementiert, ohne dass ein zugehöriger fehlschlagender Test existiert. Die User Story ist nur dann fertig, wenn alle Kriterien beschrieben sind, automatisierte Tests vorliegen und alle Tests erfolgreich durchlaufen. Wenn Sie diesen Ansatz konsequent verfolgen, werden Sie nicht nur neue Funktionalität testgetrieben entwickeln, Sie bauen auch ein stetig wachsendes Netzwerk von Regressions-Tests auf, die die Geschäftsregeln des Systems kontinuierlich überprüfen.

ATDD ist mehr als ein reines Testwerkzeug. Es ist ein Werkzeug der Kommunikation und Zusammenarbeit. ATDD fordert vom Product Owner, dass er für alle User Stories Akzeptanzkriterien schreibt. Er verwendet Beispiele aus der Praxis, um seinen Team die Akzeptanzkriterien zu erklären. Die durch dieses Vorgehen forcierte enge Zusammenarbeit ist der Schlüssel für die Entwicklung guter Software: Software, die der Kunde wirklich will.