Acceptance Test Driven Development

Problem statement:

In Agile project delivery, a common escalation from the client is that "the feature with expected functionality is not delivered on time, even though we shared the expectations, well in advance." The application users may complain to a support executive that "the feature of the application is not functional, while a similar feature of other applications performs." In a nutshell, a well-planned and organized software development model is also facing a communication gap between the expectation and delivery.

Solution:

Enabling BDD processes and implementation of Acceptance Test Driven Development will help to close the communication gap in Agile project development, up to an extent. In the BDD enabled environment, Acceptance Test Driven Development plays a crucial role to check whether the feature is developed and delivered as per the expectation of the business users.

ATDD is closely related to Behavior Driven Development (BDD), where the development team, QA team, and business analysists work together closely to understand the application's behavior. A ubiquitous language called “Gherkin” is used to gather the behavior of the proposed feature with the 'Given, When, Then' Format.

ATDD is a practice where the development team, business analysists, and QA team will collaboratively discuss the feature which they are planning to develop and to deliver in a short span of time. Acceptance Criteria, with examples, will be defined and distilled into a set of acceptance tests before the actual development starts. The developed feature will be considered as completed once the acceptance criteria have been fulfilled.

Acceptance Test Driven Development: How Does it Work?

1. Select User Story.

2. Write Acceptance Test scenarios based on Acceptance Test Criteria.

3. Execute Acceptance Test to “Fail” (Before User Story Implementation).

4. Implement User Story.

5. Execution of Acceptance Test by the development team.

6. Refactor code.

7. Make the Test pass.

8. Get User Story Signoff and push to the next level. Refer to the pictorial representation of ATDD workflow for more clarity.

Gherkin: A Ubiquitous Language to Describe Software Behavior

As mentioned before, BDD uses a ubiquitous language called Gherkin in 'Given, When, Then' format, which helps BA/non-technical teams to describe the feature's behavior and its expected scenarios.

Gherkin is a business readable, domain-specific language created to describe the behavior of an application or feature. It is a line-oriented language that uses indentation to define the structure. Line endings terminate statements (called steps) and either spaces or tabs may be used for indentation.

The main moto of Gherkin is to write concrete requirements (features, scenarios, and steps) with its predefined keywords. The pre-defined keywords of Gherkin include Feature, Scenario, Given, When, Then, And.

Refer to the picture for a sample of a feature file prepared using the Gherkin language.

Tools Used for BDD and Acceptance Testing

Open source tools are available in the market to perform Acceptance Test Driven Development. They are:

Steps to Implement Acceptance Test Driven Development With SpecFlow and Visual Studio in an Agile Project Development Environment

The ATDD implementation starts with features and their associated scenarios. Before starting the implementation, configure SpecFlow and Selenium with Visual Studio.

The following IDE/Tools are required for implementation:

Step 1:  Install Required Artifacts From Nuget Packages for Specflow Integration

1. Create a new Visual Studio unit test project and name it appropriately.

2. Delete the Unit Test file listed in the project.

3. Install the required NuGet packages for the project.

   • SpecFlow

   • NUnit Framework

   • NUnit3TestAdapter

   • Selenium WebDriver

Step 2: Create a Feature File With SpecFlow             

• To create a new feature file:
  • Select and Right Click the project.        
  • Click Add >> New Item.        
  • Select the SpecFlow Feature file and provide an appropriate name to identify the feature.
  • Click the Add button to create the feature file.
  • Update the feature file with the feature name and scenarios.
    

Step 3: Generate Step Definition for the Feature

Generate a Step Definition by selecting the Generate Step Definition option (right click on Steps in the feature file to get the Generate Step Definition option). 

Refer to the below picture for the Generated Step Definition file.

Step 4: Build the Project and Make Sure That Newly Created Feature Files Are Listed in the Test Explorer.

Step 5: Run the Test and Make Sure That the Test Is Failing in the Initial Run.

Step 6: Implement the Feature One-by-One in the Project. Write the Appropriate Test and Run it Again. 

(Added simple code for smooth execution)

Step 7: Make Sure That the Test Passed After Refactoring. 

Step 8: Push to Production.

Once the tests are passed with the refactored code, the  next step is to push the feature to the next phase of testing, production.

Conclusion:

ATDD enables the Agile development team to enable a Shift Left approach. It helps them to qualify feature development in the earlier stages of the SDLC and ensure quality from day one of the project.