TDD vs. BDD vs. ATDD and other Agile development techniques

Test-driven development

It's difficult and time-consuming to write and test code to meet requirements in Agile iterations. And there is always a risk that a test suite can't gauge the behaviors of software, or misses behavior entirely.

TDD accelerates software development and testing, as teams implement extremely short development cycles with simple and direct test cases. For example, software must perform a certain calculation, so the developer uses TDD to identify and test the formula against a known series of input and output data. The TDD process enables teams to identify the code's goals first, in the form of tests. Developers focus on completing only the work necessary to achieve those goals, and no coding is done outside that scope. Thus, TDD minimizes wasted effort.

To do test-driven development, first identify a behavior, output or result for the software. Prepare a specific test to gauge the desired outcome. When the software iteration fails the test, add or change code. When the test passes, the corresponding goal is complete. Thereafter, clean up or refactor the code -- ensure readability and maintainability. Rerun tests to verify that cleanup work doesn't inadvertently break the app.

There are compelling attributes to TDD:

• Developers achieve a better understanding of software requirements, as tests are written before they add or change code.
• Developers write code for testability.
• It limits the scope of development.
• Every feature or function written is tested.

There are drawbacks to TDD. Developers are not trained testers. When developers write the tests first, their errors or omissions are reflected in the code. Check tests against requirements, or foster team involvement, to prevent developers from overlooking critical test areas.

Given its relatively narrow scope and granular nature, TDD works best on small units of work. TDD might not be appropriate when iterations require broad testing, such as complete functional tests. Try this Agile development technique for modules or components of software. TDD can also help teams maintain legacy code when small, specific changes are required.

Acceptance test-driven development

Some organizations use ATDD versus TDD, as it shifts the viewpoint from functionality to business needs and user expectations. ATDD modifies the TDD development paradigm to emphasize collaboration between business leaders, users and the dev team.

Acceptance tests ensure that software satisfies business and customer requirements. ATDD combines acceptance testing with granular tests for specific, user-focused development outcomes.

Through ATDD, developers evaluate anything that the user might experience. One example is the status changes in a company's order entry system from received to shipped to paid. In addition, ATDD can check how software interacts with other platforms or systems, such as web services or databases.

From a process standpoint, ATDD is virtually identical to TDD. A developer writes a test to evaluate a particular requirement or behavior. When the software iteration fails the test, the developer adds or changes code -- and might debug it too -- to produce the desired outcome.

The principal difference in ATDD vs. TDD is the language used in test creation. ATDD tests are easily read by humans, using business- or user-centric terms in a conventional format, such as now/if/then, as opposed to the functionality focus typical of TDD. While descriptions are simple and straightforward, the actual code might be complex. An example ATDD statement reads: Given the state of a system, if a specific action or event occurs, then the state will change in a particular way.

Each requirement has a corresponding test in ATDD. Requirements without tests were not implemented properly, or at all. Tests without requirements are unnecessary. ATDD test results, however, can spawn additional questions or issues that lead to subsequent changes and further testing. Thus, ATDD can be an integral part of project evolution and maturity.

ATDD cannot be used alone. It is part of an overall test suite. QA engineers should apply other techniques, such as usability testing and security testing, to validate the complete release.

Behavior-driven development

BDD falls between TDD and ATDD as an Agile development technique. As with TDD, a developer defines a test, watches it fail on the current code version, then implements changes to achieve a pass result. The difference between TDD and BDD is that BDD tests focus on software behaviors -- how developers and business stakeholders believe the software should work. Thus, dev teams specify BDD tests in terms of software behavior and the business value of that behavior.

BDD builds on ATDD's test specifications to create a more detailed and conversational approach to outlining software behaviors. BDD specifications typically start with a title, followed by a short narrative that highlights:

• the software user;
• the software's desired behavior; and
• the benefit that behavior provides.

The BDD specification includes acceptance criteria that stipulate the initial state, events, triggers and expected outcomes -- basically an ATDD test within the BDD test. The specification might include multiple paths, scenarios or conditionals that dictate different behaviors or outcomes.

Dev teams conceive and create BDD tests early in the iteration, then collaborate with product owners to identify missing or incorrect behaviors, before they code and execute tests.

The freeform nature of TDD and ATDD doesn't lend those development paradigms easily to tools. By contrast, BDD places a strong emphasis on language formats, meaning tools can parse and process behavioral requirements to produce executable tests. Frameworks like JBehave, rbehave and CBehave read and parse keywords within specification documents, and then translate each clause into parameters for testing.

Specification by example

It's difficult to establish requirements and tests for complex software. Abstract statements in some development approaches lead to ambiguity or incomplete requirements. To use SBE, product owners, developers and testers collaborate to describe and understand software behaviors through realistic examples, as they do with ATDD.

SBE, also called example-driven development, is a beneficial technique in Agile development schemes with short iterative cycles. Organizations use SBE for requirements and functional tests on large, complex projects -- with examples agreed upon before programming.

The principal aspects of SBE are:

• Concrete examples clarify the conceptual behaviors of the intended software project.
• The software requirements created through collaboration form a single, common resource shared by business leaders, developers and testers.

The complete set of examples not only establishes the software specification, but it also provides business-centric acceptance testing criteria. The examples also form a foundation for documentation, which supports ongoing product development.

The SBE requirements document eliminates varied versions and perspectives, as well as the need to regularly coordinate between different perspectives. When new information or needs arise, organizations adjust the resource.

Support-driven development

It's a major challenge to build software that customers want to use, and maintain that product effectively through its lifecycle. In many cases, organizations write software using specifications and requirements that originate within the development team, but other teams maintain the live code. SDD, also called story test-driven development, erases these silos, as it involves software developers in ongoing product support and IT operations efforts.

When developers provide direct support and receive user feedback, they better understand the product's issues and gain clarity into who uses the software and how. Developers can use that insight to roll out future iterations of the software that accommodate user requests.

Unlike other Agile software development techniques like TDD and BDD, SDD derives requirements from post-release feedback. Direct user feedback offers compelling benefits, namely giving the customer what they really want, which is applicable in shopping, social media and other consumer-centric software. User feedback shapes the new requirements, specifications and tests for subsequent iterations.