Fundamentals of ATDD

What is ATDD?

Acceptance Test Driven Development in a general can be described as quick implementation and refactoring. In practice, we do not limit the tests for quick implementation to the unit tests and start with acceptance tests. These are higher-level tests that focus more on business value and the end-user journey, without worrying too much about the technical details.

Red-Green-Refactor Cycle

Let’s start with traditional TDD

1. Write a test and see it fail.
2. Write efficient code to make the test pass.
3. Refactor if any code smells or improvements are detected.

Now, let’s see how ATDD works

1. Write a failed acceptance test.
2. Make it pass in the most straightforward way possible (a fake implementation).
3. Refactor based on any code smells or improvement (like hard-coded data, sample data, etc.).
4. Add a new test based on a new requirement (if we need a new acceptance test, go back to step 1 ; otherwise, the process is just like traditional TDD).

Prerequisites of ATDD

ATDD has a rigid and essential requirement for developers: how to identify code smells and improvements and how to refactor them toward appropriate design. For illustration, when you turn up some smelly code (e.g., lack of abstractions) and aren’t sure how to make it better, then ATDD alone cannot save you. Even though you are obliged to use the accepted workflow of ATDD, you could end up with some unmaintainable tests in addition to mediocre-quality code.

Common Misunderstanding

A frequent misconception is that test code is the second tier or doesn’t necessarily have the same influence as production code. I would claim that it is just as important as the production code. Maintainable tests are essential to developers who have to make modifications subsequently on or add new ones. Every time you refactor, make sure you reflect on the adjustments made in the production code in the test code.

How Tasking with INVEST Principle Can Help Implementing ATDD

Another vital skill advised by ATDD is splitting a substantial requirement for smaller chunks through tasking. I would recommend every developer should learn how to split prerequisites before they even start to write their first test.

INVEST Principle

When splitting a large demand into smaller tasks, you need to safeguard that each task fulfills those qualities. Essentially, for any given task:

1. Independent
   • It should be as autonomous as practical so it can be picked up and done in parallel with other developers.
2. Negotiable
   • It should not be defined as a contract, and the scope of the task could reform based on the trade-off of time and cost.
3. Valuable
   • It should hold some business value; the attempt to develop.
4. Estimable
   • It should be measurable or has an an assessment.
5. Small
   • It should be somewhat small a big piece means more unknown elements and possibly would make the estimation less specific.
6. Testable
   • It should be clear to you, how the completed looks like by establishing some key checkpoints.

[Top]