BDD mit Test-Technologien

June 30, 2009 at 4:41 pm 1 comment


Vor kurzem habe ich einen kurzen Vergleich zwischen TDD und BDD gewagt und BDD präferiert. Bernd Schiffer meinte, die TDD-Tests seien suboptimal und wenn man sie verbessert, sei TDD genauso gut wie BDD. Das sehe ich ähnlich. Man bekommt das vor allem dadurch hin, dass man BDD-Ansätze übernimmt. Und wie das geht, will ich in diesem Beitrag zeigen.

Tests je Fixture und nicht je Klasse
Der erste Punkt ist, dass man Tests um Fixtures (getestetes Objekt bzw. Objektgeflecht) gruppiert und nicht um Klassen. Diese Forderung gibt es auch schon lange in TDD, wird aber meist ignoriert. Die meisten Unittests werden um Klassen gruppiert. BDD erzwingt die Gruppierung um die Fixture durch sein Benennungsschema (a la it “should create new meetings”). Und so ein Benennungsschema kann man sich auch in Unitttests geben. Wir haben sehr gute Erfahrungen damit gemacht, die Testklasse wie die Fixture mit angehängtem “Test” zu benennen und die Testmethoden so, dass sie zusammen mit dem Fixturenamen einen Satz ergeben. Das sieht dann in Java z.B. so aus:

public class TerminkalenderTest {
    @Test
    public void erzeugtNeueTermine() {...}
}

Diese Art der Methodenbenennung ist zumindest in Java unüblich, aber der Nutzen überwiegt hier meiner Meinung nach deutlich. Mit TestDox gibt es übrigens ein Tool, dass aus solchen Tests Anforderungsspezifikationen in Prosa generiert in der Art:
Terminkalender

  • erzeugt neue termine

Nun ist “Terminkalender” natürlich erstmal eine ziemlich langweilige Fixture. So beginnt es häufig. Mit der Zeit wird im Test aber sehr deutlich, dass eine neue Fixture raus will. Das kann man leicht daran erkennen, dass in den Testmethoden zuerst die Fixture verbogen oder nur ein Teil der Fixture im Test benutzt wird.

Assertions
Der zweite Punkt betrifft die Überprüfungen im Test. xUnit bietet die klassischen assertXXX-Methoden an. In den neuen Versionen von JUnit findet sich mit Hamcrest eine Framework, um die Prüfungen in BDD-Stil beschreiben zu können. Mit RSpec heißt es z.B. termin.start_zeit.should == @jetzt. Mit Hamcrest für Java heißt es assertThat(termin.getStartZeit(), equalTo(jetzt));. Da hat man jetzt jede Menge nervige Klammern, aber das liegt an Java und nicht an TDD.

Fazit
Wenn man aus welchen Gründen auch immer Unittest-Frameworks einsetzen will oder muss, kann man viel von BDD auch für TDD adaptieren. Das geht immer und lohnt sich auf jeden Fall.

Entry filed under: #. Tags: .

Artikel zur agilen Architektur in Objekt-Spektrum Developer vs. Operator -10 mal täglich Live gehen?

1 Comment Add your own

  • 1. Bernd Schiffer  |  July 1, 2009 at 6:21 am

    Diesmal bin ich da voll bei Dir🙂 +1 auf Alles!

    Mir fehlt noch One-Assertion, damit die Tests dem Single-Responsibility-Principle folgen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: