Development teams who adopt an Agile methodology will often champion Acceptance Test-Driven Development (ATDD) as a key driver in creating better, more user-centric software. But implementing ATDD can be a lot of technical work and requires collaboration from everyone in the development team, as well as the customer. So, how do you decide whether it’s the right way to go? We wanted to share our thoughts on why we think ATDD is well worth the effort.
What is ATDD?
Unlike Test-Driven Development (TDD) – in which tests are created from a developer’s perspective – ATDD involves writing automated tests from the user’s perspective. As part of the Agile methodology, it is designed to assert and validate the functionality of the software being developed, and encourages collaboration between a functional expert and the development team. This collaboration provides development teams with the knowledge they need to make sure the software meets the acceptance criteria.
When creating a new feature using ATDD, one or more acceptance-level tests are written before any working code for the feature itself. By doing the process this way around, developers already have ways to test their new code based on conditions and triggers agreed with the product owner and wider team. Once the code passes all of these tests (acceptance), it can then be cleaned up to meet quality standards.
Here is an example of what 5 steps in the ATDD process may look like:
Step one: Create tests
Tests are created based on conditions, business cases and functional restrictions defined by either a functional expert of the product owner. These elements are chosen based on achieving the desired functionality of the software being developed.
Step two: Run tests
These new tests are then run to failure, which shows that the required feature doesn’t already exist and that the tests themselves are not flawed.
Step three: Write code
Developers can then write the code, knowing what criteria will need to be met for it to pass in testing.
Step four: Test code
The new code is ran through the tests created in step one. If it fails the tests, the developer can then make adjustments until the test is passed and no other features are impacted.
Step 5: Refactor code
With all tests passed, the developer can then go back to cleaning up the code to meet any required code quality standards.
Benefits of ATDD
Adopting ATDD into your workflow brings many benefits for both your own team, the client/business you are working with and the end user. It gives development teams a pre-defined target to aim for that keeps everyone aligned and on track. Projects will often run more productively and result in a focused outcome that all stakeholders were expecting from the beginning. With a more collaborative and efficient process, new features will be of a higher quality, showing fewer defects and regression issues. An ATDD framework also promotes better communication in teams and distributes responsibility so that each person can take ownership of the high-quality outcome.
Have you tried using ATDD with your team in the past? Let us know how it worked out for you and if you found it useful in creating a new high-quality feature.