Revisiting BDD in Java

by Jeff Langr

April 28, 2008

My initial reaction a few years ago to BDD implementations in Java was less than stellar. Since then, I revisited them a couple times, and now I’m digging into them again. They’re still around, so someone must be getting value out of them. I certainly have gotten some mileage around naming and organizing my tests in a more BDD fashion.

Right now, I’m being lazy, and haven’t done diligent research. But my initial internet searches suggest that there are a handful of tools, none of them the de facto standard. I remember my doctor once saying, “We have about a hundred ways to treat this [a plantar wart]. Usually when there are so many ways, it means we don’t know what we’re doing.”

I started looking at one framework in more depth, and coded some straightforward examples. Didn’t seem so bad, until I looked to code a more involved assertion. Here’s one (contrived but simple) example:

    Ensure.that(name, and(contains("Langr"), startsWith("J")));

One of the core principles of BDD is “getting the words right.” I think this example demonstrates that sometimes we try too hard, and perhaps this construct isn’t a great idea for Java. The “classic” approach is easily more expressive:

    assertTrue(name.contains("Langr") && name.startsWith("J"));

or better…

    assertTrue(name.contains("Langr")
    assertTrue(name.startsWith("J"));

or even…

    assertFirstInitialAndLastName(name, "J", "Langr");

I suppose my complaint could be tempered with the fact that these kinds of compound assertions don’t occur so frequently.

Yes, sure, the failure messages are better. That’s not significant to me, given that I don’t drive my development off of failure messages. Sure, all tests fail at least once, but I usually know why they’re failing the first time, so I don’t need that message initially. Later, when they fail for unknown reasons, more information might be useful (sometimes it is, not always), but if I need that, I just enhance the assertion I already have and rerun the tests. No big deal.

Writing custom “matchers” is also an example in ugliness, given the limitations of Java. (I need to speed up my move to Groovy or Ruby, so I can stop whining about Java so much…)

I won’t give up on the Java BDD tools completely, but I’m not much happier now than I was three or so years ago.

Comments

Jeff Langr July 22, 2016 at 3:33pm

I converted to using Hamcrest not too long after this post; I now am using AssertJ in a Java shop. I became quickly convinced that the improved phrasing is very valuable.

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.