Acceptance tests, like unit tests, can be automated creating what TDD practitioners refer to as an "executable specification." The advantages of this are many:
- They can be run to ensure that new work has not damaged old.
- They can be verified to be accurate to the current state of the system at any time, simply by executing them.
- You can make changes to the system by changing the tests first, which is much safer and more efficient.
- They lower integration costs massively.
But unlike unit tests, which are inherently automated, acceptance tests can be made executable after the fact by using an automation framework.
There are many such frameworks, including Cucumber, Specflow, Robot, Fitness, and so forth. It seems like every time I turn around there is another one.
But when someone tells me "we've decided on automation framework XYZ and now we'd like you to come and teach us how to write acceptance tests" I always wince a little. Unfortunately, it happens pretty frequently. This can lead you down a bad road.
Acceptance tests can be expressed in many, many different ways. They are all rooted conceptually in Dan North's "Given/When/Then", which comes from the notion of Behavior Driven Development. But that textual form is not always the best one for a given set of stakeholders.
You want acceptance tests to be clear, readable, writeable, and modifiable by anyone in your organization with domain knowledge. You don't want any kind of intellectual barrier between the experts and the acceptance tests. Maybe you're working with a group of business analysts who are most comfortable with tables and spreadsheets. Acceptance tests can be expressed that way. Maybe the experts are accustomed to expressing themselves in mathematical symbols, or chemical diagrams, or something else. Maybe you are developing tools to be used by other developers, who'd prefer UML or OMT diagrams.
Each of the ATDD automation frameworks has different strengths and weaknesses. Specflow is good at text, literally "Given/When/Then". Fitness is good at tables. Robot is good with equations. If you pick the framework up front, before you understand your stakeholder's preferred language, then you will hamstring the effort from the beginning.
Powerful tools are very helpful, but you should not let them take over. Let the tool serve the value stream, don't force a tool onto the process. This is true of more than just ATDD, but it is a prime example. The tools should follow the need, not vice-versa.
Also, you may not find a tool that works exactly as you need it to in order to provide the most clarity to your stakeholders. Don’t limit yourself to what has already been done: Most ATDD automation tools are open source and can be customized. This is work you do only once, and it pays off indefinitely.