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
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.
