There is often some confusion between Acceptance Test-Driven Development (ATDD) and Test-Driven Development (TDD).\u00a0\u00a0 Here\u2019s a short description of their similarities, their differences, and their relationship.\u00a0\u00a0\u00a0 <\/p>\n
Let\u2019s start with their similarities.\u00a0\u00a0 They both have three words in common (1).\u00a0\u00a0 They both are aimed at creating a quality system.\u00a0\u00a0 They involve writing things called tests, but which act as precise specifications on the behavior of either the system as a whole (ATDD) or a component or class of the system (TDD).\u00a0\u00a0 The tests are written before implementation starts, so sometimes they are referred to as \u201cTest First\u201d.<\/p>\n
Now for their differences. ATDD is a communication process between the customer, developer, and tester to ensure that the requirements are well-defined. The acceptance tests created during the ATDD process should be understandable by the customer.\u00a0\u00a0 They represent the desired behavior of the system in an implementation-independent manner.\u00a0\u00a0 ATDD does not require test automation. However, usually the acceptance tests are automated for regression testing.\u00a0\u00a0 Acceptance tests do not change unless the requirements change.<\/p>\n
TDD is a developer\u2019s tool to help create well-written units of code that correctly performs a set of operations. The tests are implementation dependent. The TDD process requires automation. The tests are created one-by-one and the underlying code is revised to pass the new test.\u00a0\u00a0 All previous tests need to be run in order to ensure that revisions do not break them.\u00a0\u00a0 As a design is altered , the TDD tests will change to reflect the new design.<\/p>\n
There is a relationship between ATDD and TDD.\u00a0\u00a0 Tests used in TDD can often be derived from ATDD tests in many applications. The design process determines which code units (classes or components) interact together to pass an acceptance tests and then determines the TDD tests for those code units.<\/p>\n
ATDD may have an effect on code design. Names used in the acceptance test may be used in the code, thus providing a way to track things in a consistent manner.\u00a0\u00a0 Acceptance tests for business rule tests may be used as unit tests for methods which implement those business rules.<\/p>\n
An example may clarify the relationship. Let\u2019s take two acceptance test examples from a simple situation:<\/p>\n
Scenario: Take a Bottle<\/p>\n
Given 99 bottles<\/p>\n
When a user takes a bottle<\/p>\n
Then there are 98 bottles<\/p>\n
Scenario: Add a Bottle<\/p>\n
Given 2 bottles<\/p>\n
When a user adds a bottle<\/p>\n
Then there are 3 bottles<\/p>\n
In conjunction with these tests, the triad (business representative, developer, tester) also determines what responses the system will have when the last bottle is removed; and what response it should have if there is a maximum number of bottles (e.g. 99) and that maximum is reached.<\/p>\n
Designing a system takes these external acceptance tests and turns them into internal class or component tests.\u00a0\u00a0 The design process determines which class or component keeps track of the number of bottles; which one is responsible for handling invalid input such as adding a negative number of bottles; and how these classes and components interface with each other.<\/p>\n
There are many applications where the acceptance tests just specify the external behavior.\u00a0\u00a0 For example, for a program that solves a Sudoku puzzle, the outline of acceptance test is easy to specify. Given a puzzle, does the program create a solution that matches the Sudoku requirements? A specific acceptance test has a puzzle as the input and the solution as the expected output.\u00a0\u00a0 Designing how a system actually solves the puzzle is not directly derivable from the acceptance tests. The TDD tests help with designing the algorithm contained within a quality solution.<\/p>\n
In another application, the business says that a GPS unit must provide location information that is within ten feet of the actual location.\u00a0\u00a0 For an acceptance test, a spot is chosen and its location (latitude, longitude, altitude) is determined via independent means, e.g. surveying.\u00a0\u00a0 The GPS unit is put in that spot and the location it reports is compared to the surveyed location.\u00a0\u00a0 If the two are within ten feet, then the test passes.\u00a0\u00a0 This acceptance test does not help in designing how the GPS unit will work, only that it works as desired.<\/p>\n
There is one more issue that can confuse the difference between ATDD and TDD. Automation of acceptance tests is usually performed in an acceptance test framework (Fit, Cucumber, etc.). A TDD test is almost always automated in a unit testing framework (e.g. Junit, Nunit).\u00a0\u00a0 However acceptance tests are sometimes automated in a unit testing framework.\u00a0\u00a0 This automation does tie them to an implementation, so they become more like unit tests.<\/p>\n
<\/p>\n
(1) ATDD has at least two other slight variations \u2013 Behavior Driven Development (BDD) and Specification by Example (SPE). Note that the former has two words in common with TDD and the latter has none.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
There is often some confusion between Acceptance Test-Driven Development (ATDD) and Test-Driven Development (TDD).\u00a0\u00a0 Here\u2019s a short description of their similarities, their differences, and their relationship.\u00a0\u00a0\u00a0<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-9","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts\/9","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/comments?post=9"}],"version-history":[{"count":6,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts\/9\/revisions"}],"predecessor-version":[{"id":84,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts\/9\/revisions\/84"}],"wp:attachment":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/media?parent=9"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/categories?post=9"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/tags?post=9"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}