Acceptance Test-Driven Development: What Is It and Should I Be Using It?
Development teams who adopt an Agile method will often champion Acceptance Test-Driven Development (ATDD). This is a key driver in creating better, more user-centric software. But implementing ATDD requires a lot of technical work. It requires collaboration from everyone in the development team, including 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?
ATDD is not like Test-Driven Development (TDD), where 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’s designed to assert and validate the functionality of the software developed. It also encourages collaboration between a functional expert and the development team. This 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 it this way, developers already have ways to test their new code. This is 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 run 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 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.
Get the latest roundup of the most important, interesting and stories from the past week. In your inbox every Saturday by 10am.
How to Select Your First Process Automation Project and Calculate the ROI
Published May 20, 2020
ATDD & HonestCode: A Perfect Pairing
Published April 20, 2020
Tech Stack: Explaining Software Architectures
Published March 20, 2020