When it comes to ATDD, people, teams, and companies usually put the wrong emphasize on the elements. This blog entry is going to explore the relevant areas for successful ATDD, and how to overcome some of the misconceptions about it.

Tools

Most companies start with picking a tool. While there is value in picking a tool to automate your tests, that choice usually is not the one that delivers the highest value to you, your team, and your customer. Here is why.

Think about it. The tool you pick comes with a lot of decisions. It constrains how you think about the examples in your stories, it constrains how you can hook up the automation code to your examples. It drives decisions in your glue code. It constraints you about the amount of programming languages that your teams needs to learn. Especially when you get started with automated acceptance tests, you will not be able to deliver a good and flexible automation architecture and design. When learning a new tool, that should not be focus. The focus at this point lies on learning the new tool, and the constraints it comes with. If you intertwine that learning too deeply with too many constraints, you will not learn anything at all.

While teams new to ATDD spend about 90% of their time on learning the new tool, this shouldn’t be the case. Since the focus should resist on getting familiar with the new approach rather than the tool you should spend more time on other things. The tool is a means to an end. Focussing only on the implementation degree of your automated tool is focusing on outputs rather than outcomes.

Picking a tool for your automated acceptance tests should came last when you start with an approach like ATDD. It should be your least concern, since you can refactor your code to any tool necessary. If you don’t know how you can do this, maybe you should dive into design and architecture patterns to learn how to do this – or hire someone who can do the job without shooting you in the foot.

Templates

Depending on the approach that influenced you most, where should we start? There are some templates that help you with the first steps. For example the given/when/then templates of Gherkin constrain how you think about your examples.

Don’t let these templates distract you. I have worked in many tools using different templates. (Don’t make me name anyone.) I always found that the tool does not matter that much, so does not the particular template that underlies the tool. In fact it’s easy to re-write your examples to another template if you switch paradigms. That’s also a side-effect of the large spread of tools. Nowadays most tools and most languages support a variety of templates which makes switching between them more than easy.

For example, if you have worked with tabular data a lot so far, you can use scenario outlines and example tables in gherkin to achieve the same expressiveness. In keyword-driven tools you can use a templated test method to achieve the same. When using Gherkin’s given/when/then style, you can achieve the same using keywords in other approaches.

Most of the time, how you express your tests becomes a hook for your business stakeholders and customers. Ideally you should make tests easy enough for them to understand. The currently available tools you support you in that. Your test templates really shouldn’t be much of a concern to you, either.

Talk

The most undervalued piece of successful ATDD lies in how much knowledge exchange happens while talking about business features. To me this became clear when I realized why I wanted to introduce all of this stuff in first place. Most teams that start with ATDD realize problems after they delivered the software to the customer, and receive the feedback that the customer wanted something totally different. The primary goal of ATDD lies in understanding the business better. That should drive all your efforts.

Most teams start with ATDD without even talking to the customer or someone that understands the needs of the business better than they do. They will have a hard time when they automate 200 of the tests they thought were relevant, and the business asks for something completely different. Tooling and templating will never be a substitute for knowledge exchange. Knowledge exchange does not happen in written communication alone. Deep knowledge exchange comes with communication and removal of shallow agreements. Before even considering a tool or a template, talk to your customers, and really try to understand them, before confronting them with another tool or template.

Specification workshops should come naturally. Try to grasp the ideas of your business stakeholders there. You will have lots of time to rephrase those later in the iteration. The crucial part of the workshops lies in the understanding. Avoid talking about tools and various templates that you can use during that meeting. It will shrug your customers, and they might never return. Tools and templates will still be available, but if your customer is gone, you will have lost access to a large knowledge base.

We got it all wrong

When starting with ATDD, most teams think they should invest 90% on the tooling, 5% on the templates, and probably 5% on the talking to business stakeholders. Even though this approach matches our hunches, I think we got this all wrong. We should spend 90% of our time investigating how we can improve talking to our business stakeholders and ourselves, and spend the remaining 10% on the right expressiveness and tools that support the goals of our customers. The biggest problem with acceptance tests comes from the demand that we don’t understand the business goals well enough. So, whenever we start with ATDD, we should investigate how to improve that, rather than improve the things that business stakeholder will never be interested in in first place. I think this starts with the conversation and understanding of the business goals.

Oh, and a final misconception about ATDD: it’s not about the regression. That is a side-effect, and you should spend fewer than 1% of your time on it. If you find yourself in the position to always hunt after failing tests, then throw away all you got. The cost of test ownership is higher than the degree of benefits you get out of it. Better throws them all away now, and overthink your approach than to keep on letting it slow you down. It means less than 1% of your benefits anyways. Get rid of these if they come with a too high maintenance cost.