Wenn man testgetriebene Entwicklung (TDD = test driven development) an Entwicklungsteams „verkaufen“ möchte, trifft man oft auf Hindernisse oder Einwände:

  • Wir können nicht Code testen, der noch nicht existiert
  • Warum sollte ich Tests schreiben, das machen doch die Tester
  • Ich bin ein guter Entwickler, ich brauche keine Tests als Beweis, dass mein Code funktioniert
  • Entwickler sollten nicht ihren eigenen Code testen, das führt zu selbsterfüllenden Prophezeiungen
  • Tester wissen viel besser wie man testet als Entwickler
  • Testen in der frühen Phase kostet Zeit, die wir nicht haben
  • usw.

Was dabei außer Acht gelassen wird: TDD ist viel eher eine Art und Weise zu spezifizieren als zu testen! Ich schreibe eine Spezifikation als Erwartung (expectation) hin, spreche darüber mit dem Kunden, ob er das genauso sieht und implementiere dann bis die Spezifikation „läuft“.

Selbst wenn jemand kein Java programmieren kann, kann er dieses hier mit etwas Übung lesen lernen und sich dadurch mit kommunikationsstarken Entwicklern (ja, die gibt’s!) abstimmen (siehe diese Seite über BDD = behaviour driven development):

public class BalancetransferServiceBehaviour extends TestCase {

   public void shouldTransferBalanceFromAccountWithSufficientFunds() {
        // create mock instances
        Mock fromAccount = mock(Account.class);
        Mock toAccount = mock(Account.class);
        // set expectations
        fromAccount.expects(once()).method(“debit”).with(20).isVoid();
        toAccount.expects(once()).method(“credit”).with(20).isVoid();
    }
}

Der Code muss dazu nicht existieren – die ausführbare Spezifikation (früher sagte man auch: „der Test“) wird fehlschlagen, und der Entwickler kann den Code so schreiben, dass er die Spezifikation erfüllt.

[Diese Idee der ausführbaren Spezifikation ist schon sehr alt und wird jetzt anscheinend wieder in neuer Form populär. Witzig ist, dass es z.B. ein Open Source Tool (TestDox) gibt, das versucht, aus solchen Spezifikationen (Tests) normale Textdokumente zu generieren.]

Also sind Konflikte mit Testern eigentlich überflüssig, sobald diese sehen, dass es um maschinell ausführbare Spezifikationen als Vorgabe für Entwickler geht. Tester haben immer noch genug zu tun: Akzeptanztests, Usability-Tests, Performance- und Lasttests, Security-Tests, usw. — kein Problem!

, Agile Entwicklung