Acceptance test-driven development: Difference between revisions

Revision as of 05:13, 6 November 2015

Revision as of 10:21, 26 November 2015

Line 4:

</ref> and Story Test-Driven Development (SDD).<ref>{{cite web| url = http://industriallogic.com/papers/storytest.pdf | title = Story Test-Driven Development | accessdate = 2013-04-15}}</ref> All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own ___domain language.

See [[Acceptance_testing]].

ATDD is closely related to [[Test-driven development|Test-Driven Development]][TDD].<ref>Beck, Kent. Test Driven Development: By Example. Addison-Wesley Professional, 2002.</ref> It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses [[acceptance testing]], but highlights writing acceptance tests before developers begin coding.

ATDD is a development process using Acceptance Tests as its starting point and to establish a common means for all the parties in the development cycle to communicate.

An acceptance test is a black box test. As such, it is impossible to set the system into a given starting state without exercising the system's interface. Consequently, black box testing is a test that exercises the system through multiple states until the desired state is reached, whereupon the subject transition of the test is executed, and the concluding state verified. By necessity, a black box test is a journey, or journey test, and consequently is not a BDD test as a BDD test is only concerned with one transition. (Given a starting state, when a transition occurs, then we have a finished state). It is fair to say that a black box test is multiple BDD tests chained together in the form Given, When, Then, When, Then, When, Then...etc.

It is closely related to TDD only in the way that both tests are defined before the development code is written. In this case, the acceptance test is a story written by the BA, and once the system provides the necessary interface to the testing framework, the story can be translated into the testing infrastructure. Its not related to TDD in the sense that TDD is often used to develop the API interface as the test is written. This is possible with APIs because the test and the code itself is written in a common language. Acceptance tests most often focus on the UI where a human being looks at a web page. Computers can't look at web pages in the same way as humans can, so we use a substitute, typically marks in web pages that only appear if the page is rendered correctly. The markers in the web page are a contract of a kind, but only for the tests, so TDD gives you a valuable interface for a component, but black box testing does not.

Because of the nature of black box testing, the tests are often several orders of magnitude slower to run. Consequently they are few in number. But, they are the most valuable form of test as they most accurately prove that users requirements are met. All other forms of testing are impacted by the chosen architecture that is defined by the developer. Consequently when that architecture is modified or refactored, those tests are subject to change, whereas acceptance tests should only change if requirements have changed.

==Overview==