Behavior Driven Development

Relabeling TDD?

A few weeks ago I woke up due to Twitter notifications. These pings can be quite disturbing.. A discussion has started whether people should consider TDD as an instrument for testing or it being something entirely different. The whole group had the consensus of TDD not being about testing but rather having different goals. One tweet in particular stuck with me:

This sounds like Behavior Driven Development (BDD) is just about relabeling TDD, so people consider it not for testing but rather as a useful development tool. I think BDD is so much more. It is an enhancement of your process, something to improve communication and a tool to build the right thing the correct way. But let's look into it in details.

We all know this. Susan has a great idea. She contacts Joe (our Requirements Engineer) and tells him about her solution(!). Using this information Joe writes the specifications needed for the team to develop it. The team reads the specifications and builds the software how they understand it. At the same time Quality Assurance uses the specifications to define tests. The development is done, and QA checks whether it conforms to their understanding(!) of the specification. Passed QA Susan sees the result and is shocked. They didn't build what she wanted, and it doesn't even solve the problem she wanted to fix.

Do you have ANY idea, how many pitfalls and communication problems can arise this way? I worked on projects with specs provided by the development department. Later on we've found an analysis form which didn't make sense, so it was removed. During user acceptance testing this was highly criticized, as it was missing. It didn't make sense at all, but we had to include it, which delayed the project for a few months.

So where did we go wrong? Firstly Susan provided a solution, not her idea. Joe on the other hand had to create specs based on this (which is already a huge problem if the requirements analyst doesn't realize he gets a solution and not the idea). So his understanding is what will be passed on to Development and Quality Assurance. Both teams, as they don't work together, create their understanding of the specs, which more often than not, is not the same. This is even the case if you use Scrum or other Agile methods. It might be smaller scaled, but still the same communication problems exist.

How can we fix it?

Once again Susan has the idea. She walks up to Joe and provides her solution (same problem as last time). Joe walks with her through some concrete(!) examples and quickly identifies the idea. With the input Joe got from Susan, he meets with the development team and together they create the requirements resulting from Susan's idea. They structure these based on a specific format (Gherkin would be one of these) and based on concrete(!) examples. Based on these concrete scenarios both Quality Assurance and the development team can create the product. Susan at the same time can use these to check whether this is what she wants. Oh and if you have Test Automation go ahead and use the scenarios to create your tests!

Look how often I've used the word: concrete! This is the important part. Don't try to figure out, what people want. Let them tell you! Use scenarios to validate your understanding. The scenarios help you to build what is right. To build it the right way we use our old ways. TDD is for developers to work with. You have the scenarios to create tests, so the acceptance tests are specified.

As always there are some pitfalls. I've seen companies thinking BDD is just about writing the requirements in Gherkin. Let the developers implement these requirements. They forgot about communication. Having the developers out of the loop might create some scenarios, but a lot of requirements are unknown. Looking up to my experience above: The team knew the analysis form was useless. Having created the specs together there wouldn't have been a problem during user acceptance testing (and a delay of 6 months). This was not really an error of the team, rather of the company as they had rigid structures and didn't include development during requirements engineering.

BDD is supposed to be large scale TDD as well as easier to understand for non developers. We have a scenario which describes the expected behavior. Oh.. wait.. we can use that as a test! But seeing BDD only as an advancement in TDD would not give credit, where credit is due. They can be compared though. Both create tests in the beginning, and use these to check wether the implementation does fit the requirements. The difference is the scale.

I've talked a lot about communication. It's the hardest part to get right and sadly a lot of developers just suck at it. Make way for it. Learn it. And make sure your company supports it. In our example app we don't need BDD, but it might be something you should consider for your next larger project.

Next: Automated UI-Testing for iOS

Previous: Advanced Mocks in Swift

Related posts:

To start is probably the most difficult step. It feels like taking the first step demands more courage and effort than all the following steps combined!

Finding a good chiropractor involves conducting some research and considering certain factors. Here are some steps to help you find a reputable chiropractor: Remember, it’s essential to trust your…

Aurumara is an inspirational jewelry brand symbolizing elegance & self-belief accentuating unique traits that make YOU. This jewelry brand was created to celebrate the confidence and uniqueness of…