I first was introduced to Acceptance Test-Driven Development (ATDD) at a meetup run by ASOS technology. I loved the theory and ended up joining ASOS where I was able to see it in practice. Working within a cross-functional development team, through pair programming or working at the same time on feature code and test code. This was an amazing environment to work in where I learnt a lot, especially the whole team owning the quality of their software. ATDD encourages QA engineers and developers to work together on implementing the behavioural tests. Meaning edge cases and testers mindset is applied right from the beginning of the development cycle. Behaviour is documented as part of the feature development as well meaning you have live documentation about what was actually implemented.
Gojko Adzic defines ATDD as:
“Write a single acceptance test and then just enough production functionality/code to fulfill that test”
Introduction to TDD
In this article I will aim to distinguish between ATDD and Test-Driven Development (TDD) and also explain the differences between ATDD and Behavioural-Driven Development (BDD). As well, I will:
- Explain how ATDD fits into your agile testing strategy.
- Detail the flow of ATDD using a simple example using frontend technologies and how it can be applied for backend.
- Share the importance of not forgetting about visual changes when it comes to test coverage.
Finally, if you want to learn more about this then you can take my course on test automation university: Acceptance Test Driven Development for the Front End.
My introduction to ATDD
We would create pull requests which included the feature alongside unit, component, and acceptance tests. I was fortunate to be on-boarded onto the team by a brilliant engineer, who walked me through the process step by step. One of those steps was using Gherkin syntax (Given, When, Then) to create the acceptance test scenarios, right at the start of development of a feature. This would allow the QA Engineer to share the Gherkin scenarios with the whole team including the Business Analyst, Solutions Architect, and Developers. Everyone understood and “accepted” the test cases before they were implemented, saving any wasted time and energy.
How ATDD differs from other strategies
The focus of ATDD is on behaviour of the user. Acceptance criteria are always written from the user’s perspective and aim to explain the requirements of the user to be able to be translated into software (this is harder than it is described). The difficulty with writing code is that you can lose sight of the user requirements during the development process. Thinking about design patterns, writing clean functions and classes, and engineering for future scaling considerations. It’s only human to think like this and get lost in the details. Hence, the addition of acceptance tests can help align the code implementation with the acceptance criteria.
TDD vs ATDD
TDD focuses on the implementation of units of code or isolated functions. TDD is used within ATDD as the inner circle (refer to ATDD diagram). For example, where you have a username field on the registration page, the username input tracks changes when the user types into the text box. This may be abstracted within the code to a function which could be tested in isolation. This is an implementation detail which would not concern the user; they just expect to be able to use the input field without concerning themselves with the implementation detail. ATDD focuses on the overarching behaviour from the perspective of the user.
BDD vs ATDD
BDD can be used as part of the ATDD cycle to describe the acceptance criteria. BDD describes the process of how business requirements are documented or designed and is often referenced when using Gherkin syntax. The Gherkin requirements can be translated to acceptance tests. The difference being BDD relates to the business phase and ATDD relates to the development phase.
Agile testing vs ATDD
Agile testing is the strategy or practice at which ATDD could be part of. Agile Testing involves testing throughout the software development lifecycle. For example, within a scrum agile environment, you would think about testing requirements through to testing in production. When analysing the test strategy for an agile team I would think about including ATDD as part of the continuous testing as this would enable teams to deliver quickly and with quality.
Example of ATDD in action
As previously mentioned, we are using a registration page as an example. We want to build the username field using ATDD starting with the Minimal Viable Product (MVP), which is the username input which accepts any value – no validation or username duplication checks.
- Write the acceptance test for the input box.
- Use `data-testid` or accessible html tag/attribute.
- Run the acceptance test – which fails.
- Write the unit test for the input box.
- Run the unit test – which fails.
- Implement the MVP username field.
- Run both acceptance and unit tests.
- Refactor code if required.
- Add visual tests for CSS / Responsive design.
At this point, you continue with the loop, adding additional features to the username field such as validation using the ATDD cycle.
Writing your acceptance tests
You can write your acceptance tests using whichever framework or style you wish: Using native programming constructs with plain English test names and wrapping test scenarios in well described statements. Or with the use of a BDD framework which offers gherkin syntax abstraction. I would recommend only using the abstraction if you are communicating the scenarios with business users or, even better, collaborating with them on the scenarios. However, sometimes your test report with clearly described tests can be just as easy to read without the complexities and maintenance costs of using a BDD abstraction.
Using data test ids
As mentioned in the example (1a), a way to make acceptance tests easier when writing the tests before the code is implemented is to default to using data-testids. Primarily decide on a standard for your test ids within your team (e.g. feature_name-{element_type}-{unique identifier}, curly brackets text if required and to make them unique). Then whenever you want to reference an element, you can work out what the data-testid will be based on the standards. Even if you don’t do this upfront, you can easily substitute the id quickly after the component is implemented. The other way to achieve this is to make sure code that is implemented follows HTML Semantics. Therefore, you will be able to reference the appropriate html tag or attribute.
Benefits of ATDD
As described in the example, ATDD means you can make changes to the component in development without risk of breaking other parts of the feature. Additional benefits include:
- Collaboration of test cases through plain english acceptance test scenarios
- Acceptance tests part of the definition of done
- Code coverage doesn’t get added to the backlog after the sprint
- Developers and Testers working on acceptance tests
Code coverage !== test coverage
As mentioned in the benefits, ATDD helps achieve code coverage at the time of development. However, this does not mean all cases are covered, especially when it comes to considerations like responsiveness and visual elements. This is where visual testing really helps cover those cases not achievable by automated checks. Using Applitools, we can easily configure our automated checks to run against multiple browsers and devices to see how the feature looks. The flexibility to be able to use your testing framework of choice and run the tests in the Ultrafast Grid means you can capture a wide range of issues not covered within functional tests. Again, building in visual testing into the ATDD cycle means that it’s not an afterthought and the backlog doesn’t contain lots of bugs related to responsive design.
Conclusion
I hope you have takeaways from this blog of how you can engineer this within your team. Hopefully, I have articulated that you can be flexible in how you want to deliver it and it is an approach rather than a defined set of rigid steps. ATDD does require discipline and collaboration to follow the process for every feature. If you want to learn more and walk through the steps using React, Testing Library, and Cypress then head over to my course on Test Automation University, Acceptance Test Driven Development for the Front End.
