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 a technique called Test Driven Development (TDD) but is more advanced when it comes to development processes. As TDD states “the tests should be written before any functionality is implemented”, BDD adds “the behavioral nature and business flow of the tests should be established before they are created”.
With BDD, you’re building up an accumulation of acceptance tests driven by business value, which 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 you lack some of them you will probably struggle and not know whether you are on the right path. Often the behavior that is most important to the user it is not so obvious to the developers.
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:
-
JDK environment
-
NodeJS
-
Visual Studio Code editor
-
(Chrome)Driver.exe
2. NPM packages:
-
cucumber
-
protractor
-
protractor-cucumber-framework
-
selenium-webdriver
3. Extensions:
-
Cucumber(Gherkin)
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 think that this article was useful and you’ve learned from it, but you are always up for more knowledge on the subject, check out the other blog entries here at IBORN , there might be another one or two right up your alley.
