Acceptance test-driven development

What is ATDD?

In practice, normally when each business needs software they will start with writing the requirements and features then give the requirements to the development team and do the acceptance tests before the software goes to production; however, most of the time developers usually misunderstand the requirements, for the product in the user’s mind and developer’s mind are not the same. To avoid that issue we need ATDD.

Acceptance test-driven development is a development methodology based on communication between the business customers, the developers, and the testers. It aims to help development teams understand more about user stories and details of the acceptance test.

By continuously testing for the existence of a given functionality, and writing code to introduce functionality that can pass the Acceptance Tests, developers’ effort is optimized to the point of just meeting the requirement.

To make both sides understand each other’s scrum is required, and more things need to be discussed are the flow of features, the definition of Done (DoD), and Acceptance Criteria. After the developers know the Acceptance Criteria, they can start to develop the software, do the demo and testing, then deliver and start with a new feature.

Advantages

• Clear goal: The whole team has a clear goal from the beginning to pass all the test cases which lead to the expected outputs.
• Efficient Collaboration: As everyone on the team has a clear goal, each team member can edit each other’s code confidently, the test will inform if the changes made have an unexpected output.
• End-user satisfaction: The test cases encourage developers to think from the perspective of the end-users.
• Executable documentation: With the test case documentation it helps the developer to understand more about how their code would work.
• Maintainability: Easier to maintain and refactor code because the test cases help support.
• Scope problem: There will be no chance to skip the testing step as the test cases were written before development.

Disadvantages

• Complexity: developers may overthink and lead to an over-complicated code structure. And the test cases are hard to write when the particular features are under development.
• Redo test: If the designs are not clear from the beginning or there are changes during the process, this will force developers to redo the test.
• Simple design: Writing test cases first may lead to more focus on the simplest design without thinking ahead.
• System degradation: The whole team has to agree on the test if everyone does not agree or does not maintain correctly the whole system can be degraded.
• Time investment: with acceptance tests driven development, tests are written before code so it consumes the time before actual implementation which isn’t part of the product.

Managing Software Used

Business Readable Domain Specific Languages are used to describe how the software will behave without going into the details of implementation. This is especially important in ATDD, where the focus is on keeping the product in the developer’s and the customer’s mind as similar as possible.

Some examples of Business Readable DSLs are Gherkin, Cucumber, Specflow, and Behave. These managing software are mainly used for documentation and automated testing. Here we will highlight the usage of Gherkin, a commonly used Business Readable DSL.

In Gherkin, cause and effect are displayed in this syntax:

Feature: Title of the Scenario

Given [Preconditions or Initial Context]

When [Event or Trigger]

Then [Expected output]

The relationship between Given, When, and Then:

The most important terms used in Gherkin syntax are as follows:

• Feature: each file should describe a singular feature
• Scenario: each feature file can contain multiple scenarios
• Background: a keyword that helps give context to a scenario
• Given: a keyword that describes a predefined state of the system
• When: a keyword that defines user actions
• Then: a keyword that defines the outcome after the action
• And & But: used to define multiple Givens, Whens, or Thens

The ATDD lifecycle and Gherkin:

The best practice of using Gherkin is where each scenario is separate, and where every feature can be executed along properly. Having scenarios connect properly with your requirements is crucial, therefore combining common scenarios can help. Each step should be modular, easy to understand, and independent from one another.

There are, however, some advantages and disadvantages of using Gherkin. Gherkin is simple and understandable for non-programmers and is a good base for programmers to use for implementation, which follows proper ATDD methodology. However, it requires a large amount of business collaboration and engagements.

Since Gherkin emphasizes heavily on modular and well-defined tests, poorly written tests can lead to a lot of test-maintenance costs, which is the reverse effect of what it should aid in. Besides, some scenarios are unsuitable for Gherkin, where the scenario might be too complex to clearly define.

Example of ATDD

LINE Application: A communication application that allows users to send and receive text messages and online phone calls using voice over IP.

A typical Gherkin scenario for a login function:

Feature: Login functionality of the messaging app LINE.

Given: I am an existing LINE user and have an account.

When: I enter a username as my username.

And I enter a password as my password.

Then I should be redirected to the home page of LINE

A scenario for user authentication:

Feature: User Authentication Background:

Given the user is already registered to LINE Scenario:

Given the user is on the login page

When the user inputs the correct email address

And the user inputs the correct password

And the user clicks the Login button

Then the user should be authenticated

And the user should be redirected to their dashboard

And the user should be presented with a success message