Friday, February 8, 2013

Poor man's BDD with JUnit Rules

There's plenty of buzz in the agile circles around Behavior Driven Development (BDD) as a compliment (or replacement) for standard TDD development. Plenty of really powerful frameworks like Cucumber, JBehave and easyB have popped up to give full stack implementations for developing Java apps with BDD. These are great frameworks and provide a lot of features, but if you work in a place where change is a dirty word, trying to get a team to use one of these great frameworks might be a little more than you can handle.

Another option to slowly move toward a BDD model, would be to use what I call "Poor Man's BDD". Have the 3 Amigos (DEV, SME/BA, QA) sit together and define your stories or acceptance criteria by highlighting behaviors. For example, in a BDD style that might look like: From there you can use this simple java annotation to add business friendly documentation/reporting your JUnit tests.
The last part you need is a way to run a report and show your business and QA counterparts that you have coded the tests according to the specification. For that, you can use a JUnit rule and your favorite logging solution (I picked Log4J, because...why not).
The only change your team mates need to make is to annotate their tests with our annotation like this: That's it! Your developers don't have to stray from their JUnit big green bar in eclipse (it was hard enough to get the team to use TDD, you can't change it now!), you have achieved some readable documentation of what the test is actually testing AND you can export the results of your tests into a file that you can give to your business stakeholders with a report that shows I have addressed the business cases with tests and they all pass. Like so:

Is it comprehensive? No. Does it actually prove that you are asserting the right things within the guts of your test? No. What it does is add some simple sugar to team's existing JUnit skill-set to build requirements based on examples of business behaviors. The next step is to start looking into easyB or Cucumber and start building executable business specifications.

Here's the code => clicky. Hope this simple solution is helpful.

3 comments:

  1. I like the idea, too. One (small) issue with the Testrule is that it makes every Scenario-annotated test run twice. A solution to this issue it to implement the rule-class by extending org.junit.rules.TestWatcher.

    ReplyDelete
  2. +1 For TestWatcher

    ReplyDelete