Acceptance Test-Driven Development

Wouldn't it be great to have a technique that prevents defects from being introduced into your code base?

That is probably the question many responsible for software development are asking themselves. Actually, such a technique has been known for as long as programmers have been writing code. How? We simply write the test before the production code and execute it.

From Stephan Schwab's blog

• Benefits of Acceptance Test Driven Development
• Acceptance Test Driven Development changes how you organize your project
• Acceptance Test Driven Development brings teams together
• Cucumber: When Programmers Have a Dream

Executable Specification

With a simple mindshift we can develop software more effectively.

Instead of relying on extensive specifications, handed off to programmers as blueprints from someone else, the whole team collaborates. Together we create an executable specification, code that drives and tests the production code, that not only tells us where we are but also serves as a warning system telling us when things that used to work break.

Stephan is an outstanding technologist and coach. He is able to understand the coaching needed by a team and also update the technology stack to support the team and his coaching plan. Stephan helped us with Acceptance Test Driven Development on a number of technology stacks including web applications, Windows application and COBOL in addition to the tradition Java technology stack. I would both recommend and hire Stephan.

Cameron Wolff, ADL Nationwide Insurance, 2011

We put the focus on the expected behavior of the production code and we state that first before diving into the details. So that we get it right from the start.

By having tests in place for every piece of code we can trust our building blocks for the larger piece. Instead of believing that we may have done it right, we have proof at every turn of the way and can work with confidence. No sweaty hands before demos!

TDD vs. ATDD

Classic TDD (Test-Driven Development) and ATDD are essentially two sides of the same coin. In both cases we want to describe, in code, what some piece of software does before we write the code for it. The main difference is that TDD is by programmers for programmers and focuses on the little details so that we can create software out of many trusted building blocks. ATDD is an outside-in approach where we describe what the system does on a more granular level. Because we are looking at the system from the outside inwards we can use ATDD to collaborate well with testers and business analysts on the team.

Specification By Example

Let me give you an example

Examples are a great way to explain what someone is looking for. In conversations with other people we use examples all the time to illustrate what we mean.

As a non-developer, I found Stephan easy to communicate with and a good team player. He is able to speak in non-techie terms so we could troubleshoot together. Stephan is an asset to any team!

Noella Natalino, Metadata Librarian, ProQuest

Specification by Example is a powerful technique to communicate requirements for a software solution to the technical team that gets the point across, fosters team/stakeholder collaboration and helps to build the right thing.