The BDD Spectrum

I’ve written about options around BDD before. I have described how there’s a broad range of approaches you can choose from. At the time of that last article, I was contributing heavily to SpectrumBDD, a Java 8 functional BDD test library for JUnit 4.

A few years on, having had the option to use different BDD tools for different projects, where have I settled?

Cue The Question from Cape Town

I got a message from someone who is looking for BDD tooling to drive testing in his new team. His point of view is that you can get overwrought code writing even unit tests unless you use the techniques of BDD to focus on the spec.

Great tip there. Focus on the specification and observable behaviour, not the steps of executing a test, or the internals of the implementation.

While it might be cheap to rehash an email I sent to a fellow professional as a blog post. Here are some highlights.

Choosing a BDD Framework

I think there are a few considerations when choosing a BDD Framework.

  • Is the implementation easy?
  • Does the framework support the methodology we want to use?
  • Is it easy to solve problems that arise?
  • Is this common in the industry? in other words, do people out there already expect to have the skills?

Is SpectrumBDD, on which I slaved a few years back, a fit for the above?

What’s Leading in Java Automation Testing?

My current feeling is that there are only really two leading approaches, which you can even use in tandem:

  • SerenityBDD – this is a reporting/instrumentation rule on top of JUnit4 tests which encourages BDD style testing
  • Cucumber – this is a tool which encourages the writing of specs in plaintext, which are then coupled with snippets of test execution code to make test execution happen

When to Use Tools for Unit Tests

Does Spectrum get a look in for unit tests?

I don’t think that unit tests should be written in Cucumber.

I think using SpectrumBDD to write unit tests is possible, but a bit clunky – working around some of the functional issues with final references etc.

I personally prefer to use BDD techniques to write JUnit 5 tests. Using BDD Mockito, and AssertJ to express behavioural tests.

That said, plain SerenityBDD can be used as an instrumentation layer on top of JUnit4 tests and encourages a more BDD approach. It may be overkill.

Acceptance Test Frameworks?

Though BDD can be applied at all levels, the big BDD frameworks seem to fit Acceptance Testing better.

For acceptance tests, operating at a higher level of abstraction – tests across several classes, or tests over a whole service, or tests across several services, then my current tool of choose is Cucumber, for which partnering it with Serenity provides some extra benefits.

Using Cucumber on its own is a perfectly reasonable solution and would come as no surprise to most development shops.

Making a Choice

You have to choose the tool that thinks the way you do, and which fits your team.

I tried to solve some problems with Spectrum that were clunky in Cucumber, but it remains a nice solution that even I didn’t use in the end. You can solve those problems with well-written Cucumber code, and you can get some assistance in instrumenting Cucumber tests by adding in Serenity.

That Serenity limits you to JUnit 4 may be a reason not to use it.

In these situations, the best decision is often the most obvious and boring – i.e. nobody will remark on your choice if they look over your shoulder.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s