In recent times the shift left is happening trend in the software DevOps.

DevOps is basically a ladder between development and testing which enables continues integration and continues development.

In the context of DevOps shift left testing is getting more focus as the strategy of shift left is to test early and deploy early. (shifting testing left side of the “requirements to development to production roll out” pipe line).

That means the automation testing should happen as and when build is getting generated. The cycle times of test execution must be low so that build can be generated quickly. To do this seamlessly with conventional automated testing tools is a challenge as these tools typically have different UI and not integrated with development environment.

So the ideal solution is to have IDE(Integrated Development Environment) or a plugin for development environments. Be it Microsoft Visual Studio, be it Java Eclipse or be it any other development environment, Test Automation can be performed right from IDE right from the same development environment integrating with favorite unit testing frameworks.

This will be one shop stop for both development and testing.

Selenium is already being great tool for Test Automation right from integrated build environments for C# and Java for Web Applications.

So where will BDD fit, BDD is approach for faster testing and provides transparency in testing “what you write as requirement (feature) is what you test”. Requirements are written as features and features are implemented and tested.

It starts with Features, which all features we want to include. And each features contain multiple scenarios and each scenario can have flavors with different data sets.

Application -> Features – > Secenarios -> DataSets

Let us try to write the feature and scenarios for Calculator application in general to get to better understand, and after that we can see how these features can implemented.

Lets first create feature file as calc.feature  and write following.

 

Then lets choose how many types of scenarios we want to cover for this feature and tag them separately.

@Basicoperations

@Advancedoperations

Let us take in each of these operations lets write basic scenarios with keywords Given, When and Then.

Given describes or sets the context of the scenario under stated environment. The best practice is to check the system state. Its like prerequisite for the given scenario.

When describes the state change parameters. Like user actions to move the system from one state to another state.

Then describes the consequence or result caused by the state change. Its like if when is the cause Then is the effect.

And is key word will be used to add multiple whens or multiple Thens.

But is used in the same context as then and mostly used for negative testing.

Here is how a scenario looks like.

The tag @Basicoperations is like category of the test.

Scenario Outline can contain multiple examples, It is always better to write as Scenario Outline instead of just scenario so that we can specifically mention the parameters and looping of the test data is also possible.

We have several ways of writing the same scenario. Its better to write the scenario as re-usable blocks so that the steps can be re-used.

Let us take another example to see how we can re-use the same steps.

In the below scenarios same steps are used as above scenario and just the operation is being changed.

Let us look at @Advancedoperation description and figure out how we can write the detailed re-usable steps for more advanced operations.

In the above we can see multiple and statements and some of the “And” statements are similar. The above scenario enters data in below form. the multiple And statements enter the values in the respective text boxes.

This is very small example of how we can write BDD tests, I will try to explain how this can be implemented in next blog.