I have been thinking for a while to write a piece on BDD (aka Behaviour Driven Development), not that it was absolutely essential (I consider myself as lazy) but more so because there is very little write up available on relevance of BDD and its use in a .NET environment. BDD is also known to many in the community as ATDD (Acceptance Test Driven Development), certainly for some similarities that can not go unnoticed.
So really, why bother about BDD?
It starts with the notion ‘Did you give me what you promised ?’
I am consciously not going into the detail definition of what is BDD, hoping that you have some amount of understanding of what it is. For absolute beginners, this is just another way of interpreting your solution by its behaviour rather than objective feature (and expressing your development and testing in a business knowledge that is ‘executable’).
In traditional software testing, test cases are derived from the requirements (and nothing wrong in it!). The fact is – customers, at the end, will be bothered more about the solution, less about the ‘requirements’ and what has been tested. The delivered solution/product will always be matched against the customer expectations (and even sometimes, unrealistic expectations).
This is where the problem creeps in!
The bi-directional traceability matrix to establish what links stated requirements and delivered product will be of some assistance but often that’s lost in translation. With the adoption of Agile delivery approach, things have become a bit simpler but the problem doesn’t go away.
Make a living document: whose document is it anyway?
BDD fills that gap. That very difference where features promised to be delivered never met the customers’ acceptance because of a communication gap between what is expected versus what is delivered.
When you think a bit deeper, there are two direct benefits delivered by BDD:
- You can organise your requirements (feature file) and test scenarios at the same place following a structured format. These test scenarios will often be the ‘Acceptance Criteria’ for the feature and will be easily monitored (and managed) by business (PO, Business Analyst)
- Most importantly, these test scenarios written in natural language are ‘executable’. Yes, you can literally click the run button and the programs takes over from there. Which means, they can be integrated with the build (and follow continuous integration)
It almost becomes the single source of truth in delivering the software that can be integrated with your solution and the whole suite can run as a single entity. Remember, all that BDD is giving you a platform to structure your tests in a natural language. That means you can write any of your tests including, Unit, Integration and UI level automated tests.
I understand that – Tell me how to apply it?
Often seen, organisations using the BDD approach are not applying it right, leading to a non-optimal usage and less effective implementation. We have to keep in mind that our objective here is to bridge the gap between business, developers and test people and BDD is giving us the interface to do that. To write an effective feature file, these three have to come together and will have to agree before a feature can be implemented. An understanding and agreeable environment is the key here – supplemented by the inputs from all three of them to make the BDD feature file more comprehensive, correct and complete.
Always keep in mind that we develop or test something based on what is important for the end user, not what we want. End user behaviour is the key in adopting a BDD-style framework. By elevating your focus from object to feature, you are able look through the lenses of a customer, enabling an app with a great user experience.
Enough words, let’s see some action
Here is a simple demonstration of the way you can take a BDD path and implement using Specflow/Gherkin in a ASP.NET MVC app.
Project set-up:
If you are using Visual Studio 2010 or 2012, install the library from Visual Studio gallery along with the Nuget packages.
https://visualstudiogallery.msdn.microsoft.com/9915524d-7fb0-43c3-bb3c-a8a14fbd40ee
Check the Integration section of the Specflow website for details:
http://www.specflow.org/documentation/Visual-Studio-2012-Integration/
The Specflow website has all other relevant details on similar implementation using other Visual Studio versions.
Feature file and Executable tests
Below is an example of a typical feature file where you will write all your tests for a feature. It is always a good practice to organise your tests by feature and you can logically group them under a feature file. The feature file contains the behaviour of your application components and your tests are aligned to verify those behaviours. Once you have outlined the tests, you can generate a Definition file which will contain your underlying code.
The Definition file will give you to structure your code aligned with the scenarios outlined in the feature file. They will be replaced by the actual code that will allow you to run your tests – be it Unit, Integration or UI.
After you write your own piece of code in the bindings, it will look something like this. (You will continue to write the page Object Model to simulate the user behaviour in a similar way)
And, finally, one last thing before you run. Check that you have the right Test runner in App.config.
And you are all set to go!
There is no denying fact that BDD can instil good discipline. It is not something very new, not something radically different from what we have been doing to date (you probably already use ‘Arrange-Act-Assert’ anyway), but a great way to organise your thoughts, put them in a live document that is ‘not just another document lying somewhere’ but something you can execute and get an instant feedback.
So, why not give it a go in your next project?