Posts Tagged ‘java’

Cucumber Goodness

Posted: October 30, 2012 in Cucumber
Tags: , ,

I manufacture my own fairy dust. It’s a special blend of Cucumber goodness and a few of my own secret ingredients. I have to admit though, it’s not a perfect formula. I try to sprinkle the stuff on everyone I come into contact with on my project. Some people are able to shake it off pretty easily. Others can’t imagine how they thrived before without it.

In my magic kingdom we are using Cucumber to breakdown our story into scenarios. It’s a process that we do before development that we call our BDD sessions where we pull in the QA, Developer, Dev Lead, and BA to outline our scenario titles and define our Given, When, Then steps. During this session we uncover all sorts of goodness:

– spikes for architecture concerns
– questions for the PO to clarify requirements
– shared understanding and interpretation of the story
– tasks / questions for the developer owning the story to address

After the session, we publish our feature file as a pull request in GitHub where the entire team has an opportunity to review. Our BA creates a task for each scenario, and works through any open questions. Developers work through each scenario, moving the scenario task to completed once the code and tests have both been completed. In my ideal world (the fairy dust formula and our Continuous Delivery isn’t quite strong enough yet), after every scenario is completed our QA tests and provides immediate feedback.

If our QA finds a defect, it typically identifies a scenario that we missed during our BDD sessions. We create a new scenario for the defect, and we’re more likely to consider that scenario in future BDD sessions.

As a Dev Lead the biggest benefits that I receive are:

– Dev Done is when all scenarios have been completed. This definition doesn’t change based on the developer.
– Requirements live alongside the source code. No hunting through old project tickets or emails containing excel spreadsheets.
– High confidence level that new development isn’t breaking existing features.

Having lived in my magic kingdom for over a year now, I have run into a few trolls:

– Higher ramp up time for new developers
– More time spent on test code for some Devs than actual code
– minimal Cucumber tooling and IDE support
– initial reluctance of BAs to give up their excel spreadsheets

I’m pretty happy in my kingdom but am always looking for ways to improve. Next goal is how to get closer to CD.


I recently ran into a test discrepancy where my test was failing when running it via the maven surefire plugin, yet it passed when I ran it through IntelliJ’s JUnit runner.

After spending a ridiculous amount of time on this issue, I was finally able to pinpoint the discrepancy to the Java 1.4 introduced “assert” statement and the differences in the default behavior of the maven surefire plugin and the IntelliJ JUnit runner.  The maven surefire plugin (v 2.7.2) enables JVM assertions by default.  IntelliJ’s JUnit runner does not (v 9.0.4).  My test in question happened to be failing due to a failing assert in an included xml parsing library.

To change the default behavior of the JUnit runner, edit the Run/Debug configurations, select Edit Defaults, select JUnit, and add “-ea” or “-enableassertions” to the VM parameters.