Behaviour Driven Development: The Foundation of Excellence

Editor’s note: Interested in the Engineering team and what they get up to? They’ve got their own blog over at engineering.brandwatch.com. Head over there for insights into what makes them tick, what they’re working on and other developments behind the scenes.

---

At Brandwatch, we focus on driving development in a number of ways. We use Behaviour Driven Development (BDD) because it fits into our ecosystem seamlessly. So, is it a good choice?

If you are using a hammer for a screw, then you are doing it wrong – use a screwdriver instead.

BDD is all about thinking about user perspective. The decision to use specialist tools like Cucumber depends on our company structure and long term goals.

Do you follow BDD correctly?

If your answer is ‘yes’, then in our opinion, you should discuss what tools makes more sense. Choosing a random tool can backfire and affect resources. Check out these handy links:

• How…You may be ‘cuking’ it wrong
• Why…Cucumber needs BDD to succeed, not the other way round.

It’s my opinion that Cucumber is the best tool for BDD. Have a look at this famous meme, depicting exactly why BDD is a need, and let me explain why Cucumber is the ultimate execution tool for us here at Brandwatch.

Functionally, the implemented product can be a working ‘swing’, but…

Is that exactly what was asked for?

BDD can close those gaps, as it is a communication and collaboration framework for developers, QA and non-technical or business participants in a software project.

Dan North, the developer of the BDD, described it as: “…a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

For most feature requests and new functionalities, the requirements only reflect the tip of the iceberg – which can get messy when development starts.

 

The only way to tackle such situation is to write an acceptance criteria in a human readable language. Gherkin, the language used in Cucumber, acts as a bridge easily and the BDD execution works like a charm for us.

As a stakeholder, I would not worry about how we create the feature internally. If I have asked for a Navy Blue Button for a job, I would expect it. I wouldn’t expect to see a Peacock Blue Slider for the job, even if the functionality is exactly the same.

Lets consider this hypothetical example:

How product owners describe it:

“Can I have an option to change my password?”

How we write it internally and verify with the product owners later:

Scenario/Story: As a registered user I want to be able to to change my password.

Given the user is a registered user

When they choose to change their password

Then they will be able to change their password

This description guarantees that everyone is on the same page and there is no confusion.

We don’t specify how we do it in the code level and keep it very high level for normal users. We share this to our stakeholders and get an ‘OK’ first. If a developer misses one step, then it will get failed in QA and will get fixed before we demo the feature. This just makes everyone’s life easier.

Now, until now we have only been able to see the tip of the iceberg. The real deal is hidden beneath the surface of our Product Development team.

A JavaScript developer builds the visualisation details which the product owners asked for, Java developers neatly tie up the functionality from backend and the QA will ensure what Product owner’s expectations are achieved and it behave as required.

To do this in QA, we use Cucumber to run the acceptance criteria and the underlying Ruby code. The step definitions behind the scenarios you see above drive the code to ensure the acceptance criteria does exactly what they should.

We automate all testing (it depends on the complexity of the feature under test), but we do always use the acceptance criteria to verify the features we test.

---

 When the feature is ready

• We test them on our test environments mimicking the data (if needed) and publish them on live environment for the product owners.
• We get feedback and improve accordingly if they have any more suggestions.
• The product team(s) then go to the product backlog and work on the next story (request) and repeat the above for every feature.
• We maintain the good communication which is extremely necessary on Agile Scrum.

Do you use Cucumber? How do you find it?

---