Vergleich: BDD und TDD

Als XP-Jünger der ersten Stunde wurde ich bereits früh von TDD (Test Driven Development) infiziert. Irgendwann kam eine neue Bewegung auf: BDD (Behaviour Driven Design). Wie viele andere TDDler habe ich lange nicht verstanden, was der Vorteil von BDD sein soll. Das ist mir inzwischen klar geworfen. Ich möchte versuchen, einige der Vorteile in diesem Artikel anhand eines Beispiels zu vermitteln.
Als Beispiel verwende ich mein Terminplaner-Beispiel in Ruby mit RSpec als BDD-Framework.

Im Terminplaner-Test testen wir beispielsweise das Erzeugen von Terminen:

class TerminkalenderTest < RUNIT::TestCase

    ...
    def test_termin_anlegen
        dauer_in_minuten = 180
        termin = @stefans_kalender.new_termin(@jetzt, dauer_in_minuten, "TDD-Dojo")
        assert @stefans_kalender.hat_termin(termin)
        assert_equal("TDD-Dojo", termin.bezeichnung)
        assert_equal(@jetzt, termin.start_zeit)
        assert_equal(dauer_in_minuten, termin.dauer_in_minuten)
        assert_equal(STEFAN, termin.autor)
    end
    ...
end

Als BDD-Spezifikation sieht das ganze noch sehr ähnlich aus:

describe Terminkalender do
    it "should create new meetings" do
        dauer_in_minuten = 180
        termin = @stefans_kalender.new_termin(@jetzt, dauer_in_minuten, "TDD-Dojo")
        @stefans_kalender.hat_termin(termin).should be_true
        termin.bezeichnung.should == "TDD-Dojo"
        termin.start_zeit.should == @jetzt
        termin.dauer_in_minuten.should == dauer_in_minuten
        termin.autor.should == STEFAN
    end
    ...
end

Strukturell sind Test und BDD-Spezifikation identisch. Die BDD-Spezifikation ist bei den Vergleichen lediglich etwas leichter lesbar.
Der Vergleich termin.bezeichnung.should == "TDD-Dojo" ist der natürlichsprachlichen Formulierung "Die Terminbezeichnung sollte 'TDD-Dojo' sein." ähnlicher als assert_equal("TDD-Dojo", termin.bezeichnung).

Wenn wir Test und BDD-Spezifikation weiter vergleichen, finden wir auch strukturelle Unterschiede. So ist am folgenden Test erstmal nicht so fürchterlich viel auszusetzen:

def test_teilnehmer_einladen_und_autor_ist_auch_teilnehmer
    termin = @stefans_kalender.new_termin(@jetzt, 180, "TDD-Dojo")
    termin.lade_teilnehmer_ein(MARTIN)
    termin.lade_teilnehmer_ein(HENNING)

    assert_equal([HENNING, MARTIN, STEFAN], termin.teilnehmer)
    assert_equal(@stefans_kalender.alle_termine, [termin])
    assert_equal(@hennings_kalender.alle_termine, [termin])
end

Wenn man versucht, diesen Testfall direkt nach BDD zu portieren, stößt man schon bei der Benennung auf ein Problem. Wie soll man das vernünftig mit "it" (=Terminkalender) am Satzanfang formulieren? it "invites participants and author is participant" kann man zwar aufschreiben. Zumindest bei mir stellen sich dann aber die Nackenhaare zu Berge. Viel natürlicher scheint mir eine Aufteilung des Tests in mehrere BDD-Spezifikationen:

describe Termin do
    ...

    it "should have the author as a participant" do
        @termin.teilnehmer.should include STEFAN
    end

    it "should invite participants" do
        @termin.lade_teilnehmer_ein MARTIN
        @termin.lade_teilnehmer_ein HENNING 
        @termin.teilnehmer.should == [HENNING, MARTIN, STEFAN]
    end
    ...
end

BDD führt also auf natürlichem Weg zu Spezifikationen, die jeweils kleiner und besser strukturiert sind als Tests.

Wir haben mit BDD also in Summe besser strukturierte, leichter lesbare Spezfikationen.