I sense you might have questions as the title follows: “What has BDD as a development methodology has to do with testing techniques?”, “The name of the methodology has nothing related to testing, so how can it be used for that purpose?”, “How can you connect a concept like this with the Cucumber testing framework?” and so on.
BDD (Behavior Driven Development) originates from another technique called Test Driven Development (TDD) but is more visionary when it comes to development processes. As TDD states “Before any functionality is implemented, the tests should be written first”, BDD adds “Before tests are created, their behavioral nature and business flow should be put on the table!”.
With BDD, you’re building up an accumulation of acceptance tests driven by business value, which means that if it’s followed it leads to structured automated tests that describe the behavior of the user in the system.
But how will you know that your development is behavior driven? In my experience, that has been the most tricky part because there are various parameters and if some of them are lacking, you will probably struggle with knowing that you are on the right path and often the behavior that is most important to the user it is not so obvious to you as a technical person.
That’s when BDD conceptualization kicks in! I consider this phase as taking the QA hat off and putting the user hat on. Once you’ve specified the user needs, you put the QA hat back on and implement your specification.
When it comes to implementation, we are talking about having all specified, documented and automated in one place. To have the best of both worlds, we will need some sort of “connector” to bring the little pieces of the puzzle together, as well as an “activator” in order for the idea to be a success! Make room for Cucumber!! Such a powerful tool enables writing tests in Gherkin language, uses APIs and libraries that are available and standardized for the technology used. I applaud the idea of writing tests that are understandable for both technical and non-technical people in terms of features and scenarios that explain it further.
So, we already have the tool that understands Gherkins and then we have the execution in place. The framework depends on the technology and purposes you have in mind. You can think of the testing framework as that one friend that is always here to help and make things better. The goal of the framework is to provide a tool with different facilities to achieve the result.
Seems promising, doesn’t it? Especially when it comes to End-to-end (e2e) tests. As a category of tests, we want to implement in order to test the flow or the behavior of the system from a realistic end-user point of view, we want to include two more parties. My experience with Angular applications put Protractor and Cucumber-Protractor frameworks in the way of achieving this.
First things first, make sure you have the following installations in place:
1. Environmental installations:
Visual Studio Code editor
2. NPM packages:
Creating the feature file along with one functional scenario should have the final look such as the one shown on the picture below.
If you already get all the benefits of BDD from this session, know how to start in bringing actionable items, but you are always up for more knowledge on this subject - you’ll want to tune in to the next Iborn blogs!