What I found experimenting with BDD
There were a number of reasons I wanted to investigate Behaviour Driven Development (BDD). I had noticed teams did not have a great understanding of what behaviours their tests covered. The language to communicate when stories were done or tested wasn’t clear, in some cases what was actually tested was not communicated at all. After having read up about BDD, I was hoping that using it would give a closer connection between the stories implemented and the behaviours delivered to our users. It should also give us a common language to talk to the product owner and help her understand what we have actually done and tested.
I take part in coding katas and so decided to attempt a coding kata with BDD as a proof of concept. To be fair, I didn’t have a product owner in the kata so much of the collaboration opportunities couldn’t be taken advantage of. This was a real problem and seems like a common cause of BDD failing as it encourages a technical approach rather than a focus on collaboration which is its the real advantage. When I did use what I learnt in my real project work I did see the collaboration benefits, more on this later.
In order to do this, I wanted BDD to fit into our current technology stack: .NET, Visual Studio, NCruch, TeamCity. I was pleasantly surprised how easy this was to do. I picked SpecFlow to try first. The process was simple: Install Specflow Visual Studio extension, add the SpecFlow packages using NuGet to test project in my solution and then add a feature file. The thing that surprised me is that it all “just worked” in NCrunch. The tests ran and each step in the scenario showed the steps result, green dots shown below, and the scenarios result, green angle brackets below.
The other cool thing is the features just work in NCrunch, which means you get the great fast feedback that NCrunch provides for all your scenarios. For those who aren't familiar with NCrunch, it’s “… an automated concurrent testing tool for Visual Studio. It intelligently runs automated tests so that you don’t have to, and gives you a huge amount of useful information about your tested code, such as code coverage and performance metrics, in-line in your IDE while you type.” You can check it out here. Unfortunately, it’s not free.
The cool thing about this example is that I had already finished the code kata using TDD and *cough* *cough* object callisthenics. That means that the solution, on GitHub, contains all the TDD tests and their equivalent BDD tests. This provides a neat comparison between the two.
Notice the scenarios include IntelliSense for keywords, such as given, when, etc… it also includes steps already created. You can also see the status of NCrunch running the tests. This is pretty awesome as an IDE experience.
It does take some time to learn to write decent scenarios. I’m not claiming my examples above are fantastic. It also takes some time to figure out how to pass information between steps. Both of those are relatively solvable problems. You can argue the negative point of using SpecFlow is that it is more complex to isolate your tests given you have to use objects that are common to more than one function, as a step is a function.
After a positive first experience, I tried this out on my project for a few stories, to great effect. For example, when the coders and I (the tester) thought one of the stories was finished I showed the BDD scenario to our product owner. This led to a conversation where I realised we hadn't actually tested the thing she wanted the product to do. She could ask intelligent questions based on the language used in the scenario and we quickly could figure out what else was required to actually get done. This was a massive win for BDD, without which we wouldn’t have realised we were not checking what the feature was meant to do.
BDD, via SpecFlow and NCrunch, provide a means to improve collaboration across team functions while still meeting the fast test feedback for coders, while documenting your products functionality. I’m sure you can get most if not all of those benefits using other tools for BDD.
I found that using BDD as a method of communication to the product owner forces the coders and testers to be honest about what they are actually verifying. It creates a discussion point that was a linchpin in this process, all the while validating that you are building what the product owner wanted. It would have been better if these discussions had happened earlier in the story, this could have easily been achieved by writing the BDD scenarios and discussing them with the product owner before coding on the story started.