What is ATDD?
ATDD stands for Acceptance Test Driven Development. It is a testing first approach to development. In this approach, three different views - that of the developers, testers and business/customers - are emphasized upon to write acceptance tests before applying the functionality.
ATDD is a methodology for software development, and test automation plays an important role in it. The method brings about collaboration between developers, testers and business stakeholders, to create an optimal product.
Being a testing-first approach and making acceptance tests the foundation of the development stages, in ATDD the emphasis is on the end user. It focuses on what is actually required in terms of functionality in the system. The acceptance tests are written from the perspective of the user, before the coding starts.
To create these acceptance tests, collaborative discussions take place, answering questions from all three perspectives. The first perspective, the business side, tries to understand the problem being solved. The second, or the developers, try to see the ways to solve the problem. Lastly, the testers see if there are any fixes or improvements when going about it.
As you can figure out, ATDD has some similarities with other approaches to software development. Examples of these are BDD (Behaviour Driven Development) and SBE (Specification by Example). However, ATDD is a different approach and is not to be confused with the others. BDD focuses on the behaviour, as the name suggests. On the other hand, ATDD focuses on the final need of software development.
Past instances of ATDD
In 2000, Kent Beck published the book Test-Driven Development which had a great impact on the future of software development. In this book, Beck made a brief mention of Application Test Driven Development or ATDD. However, he dismissed the idea of ATDD and didn't feel like it would take off.
Around 2003-04, testing frameworks and tools like Fit and FitNesse started gaining popularity. Following this, ATDD also started gaining popularity, even though Beck objected to it.
Later in 2006, Dan North spoke of Behaviour Driven Development for the first time. This was initially just meant to be used instead of some TDD terms. It later turned into requirement analysis. As we've said above,BDD and ATDD share a number of similarities, so a lot of the components of BDD also started being used in ATDD.
How does ATDD work?
As stated in the definition, developers, testers and business stakeholders collaborate to design the tests based on the various specifications of a requirement. ATDD is largely similar to TDD and tests are created before even writing the production code at all. However, while in TDD, the tests are primarily unit tests, the case is different here. In ATDD, automated tests are the focus.
The workflow after the initial stage is similar in both TDD and ATDD. Developers write the code after the tests are created. Success in the tests means that the features based on the specifications have been met. The primary goal of ATDD remains the same. I.e., building a software application based on the actual requirements of the end user. It allows everyone to contribute to the creation process even if the person is not a coder.
So how exactly does the Acceptance Test Driven Development process happen? Well, there isn't a definite way that is globally agreed upon for the ATDD cycle to function. However, there are 4 steps which are common in the ATDD cycle. These 4 steps are the Discuss, Distill, Develop and Demo stages of the cycle. The essence and functioning of these stages is explained in detail below.
Discuss
The term is self-explanatory, in the Discussion stage, the customer's requirement is discussed. In other words, the end product that the customer needs from the development is analyzed in detail.
When using agile, all methodologies involve an initial planning/ discussion phase. In this phase, the developers and testers have a meeting with the business stakeholders or clients or owners of the product. Here, all the needs and specifications of the feature to be developed in a given sprint are discussed to get maximum information about the product.
Given that the discussion happens first, it's an opportunity for the team to understand the requirement thoroughly. Any doubts can be clarified in this discussion stage itself to avoid errors/ bugs in the final product. This saves a lot of time in debugging and fixing the issue at a later stage.
Often it can happen that the discussion results in a conclusion that the features are quite complex to be developed in one sprint. If the developers feel that this is the case, the user story is split into a number of individual stories. User story here refers to the features that are to be developed.
In the discussion phase, the output is the necessary set of acceptance tests. These are explained in simple words so all collaborators can understand.
Distill
The distill phase is used to actually put the tests in a format that the testing tool can understand. Or in other words, to distill the plain English tests in a format that the system understands. This makes it easier to use in the development source codes.
You may be using various different tools to actually perform the tests, so based on this, the format that your tests may have to be put in also differs. The format that you prefer could be any of the following or something entirely different:
- Code written in a specific language
- Tables explaining all the specifications
- A guide or wiki explaining the requirements in a specific format
Now, you have your output or acceptance tests ready, but there's a bit more to be done before executing these.
Develop
The 'develop' stage is the implementation stage where you develop the necessary features. This is done through the test first development approach.
In the above two stages, you end up with the skeleton of the final code that is to be used in the product tests. What remains is the process of compiling them into usable blocks of code to test the app code when needed. How you go about with this stage again depends on the tool that you are making use of.
After the final test code is written, the developers implement the needed features based on discussions in the earlier two stages and tests are run. This repeats until obtaining a success/ pass.
Demo
The demo stage is a demo of the prototype that has been developed. Once the developers are done with implementing all the discussed features, they give a demo of this to the business stakeholders. Iterations on the end product follow this stage.
Again, having such a discussion with the stakeholders after each cycle is a common feature of the agile development methodology. In these, the team discusses the various features of the product and work on improvements. Once all the implementation is done, the testers are again free to perform manual exploratory tests if they wish to. These are meant for the purpose of both finding defects and finding areas of improvement in the product.
Originally published here.
Also check out other product building guides:
Top comments (2)
Nice explanation :) This feels very similar to Consumer Driven Contracts (as popularised in microservice development, or similar contexts where multiple teams are continuously delivering changes autonomously from each other), nicely documented back in 2006(!) here: martinfowler.com/articles/consumer...
Hey Phil! Wasn't aware of this before, seems really cool. Thanks for sharing :))