During the last years there was such a strong movement toward encouraging developers to test their apps. These tests were usually unit tests. However despite being an essential part of the development of every single application, does not seem to be enough to assure that it is free of bugs (yes, I know any amount of testing is enough to conclude that…).
Professionals had started to search for a way to test from a more global insight and this is how BDD testing was born. BDD (behaviour-driven development) is based on starting development directly from the acceptance criteria extracted from the meetings and conversations that took place between the clients and the development team. These acceptance criteria come from what has to be achieved to consider a User Story as done, what in other words can be considered as ‘How can I test it…?’
There are obviously several ways to implement this. The key point is finding out how to turn the natural language expressed by the client into something that can be understood by a computer, without losing the original meaning.
As you probably already know, I have recently been developing a proof of concept written in .NET MVC, thus I am more used to working with this tech. In this platform it is rather easy to follow the BDD approach thanks to SpecFlow. SpecFlow comes with a plugin to integrate within Visual Studio IDE. With it, developers can write features files in which they include the acceptance criteria as they were previously expressed by the client. The only requirement is using Gherkin syntax. This syntax splits each criteria in three steps. Each of them starts with Given, When, Then.
From these feature files SpecFlow is capable of generating same C# code with a skeleton developers have to fill. The code they are expected to write has to deal with all the operations needed to have the browser navigating throw the site to test. In other words, the test behaves as users would do typically on the site. To connect the C# code with the browser a driver is used. There are a number of drivers available that can do this specific work. The most popular one is Selenium, which is full of features and really powerful.
Now, let’s see all this stuff in action.
First of all, we start writing an acceptance test in a feature file. This test will search for races using the location of the race as a parameter. Note that by introducing a parameter SpecFlow will generate for us the same number of test as parameters we have specified.
Another thing to pay attention to is that this type of tests can be extended by using the And clause. So if unit to do something that cannot be expressed in a single sentence, you can always add more steps to each one of the Given When Then required by Gherkin.
As I said before each step generates a method that will contain the logic necessary to perform the action described in the acceptance test:
Finally when Selenium will initialize the browser to execute the test, a decision has to be taken on which one will be used. Selenium is cross-browser. So this is another good reason to pick up this awesome piece of software.
In a few minutes you will be running end-to-end tests against your site as your client typically would do, using parameters to test different scenarios and in different browsers.
These tests will be loaded in the test explorer in the same way that a unit test would do.
Also note how as I said before two tests are generated as a result of telling the test to execute itself with two different values for the location parameter.
Finally this is a screenshot of one of the tests being executed. There is no difference between it and a user browsing across our site.
by 