You might want to begin by choosing the tool you want to use when you want to introduce ATDD to a project or client. In this article, Markus Gaertner says that this doesn’t work and shares his advice on how to overcome the biggest mistakes from the beginning when you get started with ATDD. He recommends to start with an example. Working together, the team identifies a case that would derive the greatest benefit from being automated. You should define the right approach first, the right people second, the right format third. The format we choose will limit the choice of the tool, but the tool itself should be our last consideration. Instead of thinking about the tool, we should work for clarity in how we write down our examples. All the successful teams he has worked with on ATDD shared one thing: they started with one approach, and they reflected on it regularly. During those retrospectives, they came up with necessary improvements if the approach stopped working for them. If you keep this practice in mind, you can essentially start with any approach.

Related Content:

• Python Behavior-Driven Development (BDD)
• Using SpecsFor.Mvc for Acceptance Testing
• Using SpecsFor.Mvc to Test ASP.NET MVC applications