Acceptance test-driven development: Difference between revisions

Revision as of 05:24, 16 June 2016

Revision as of 11:35, 30 July 2016

Line 1:

{{Software development process}}

'''Acceptance test–driven development''' ('''ATDD)''') is a development methodology based on communication between the business customers, the developers, and the testers.<ref name="Pugh11">{{cite book | first = Ken | last = Pugh | year = 2011 | title = Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration | publisher = Addison-Wesley | isbn = 978-0321714084}}</ref> ATDD encompasses many of the same practices as [[specification by example]],<ref>Adzic, Gojko. (2009) ''Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing'', Neuri Limited,</ref><ref>{{cite book|last=Adzic|first=Gojko|authorlink=Gojko Adzic|title=Specification by example: How successful teams deliver the right software|publisher=Manning|year=2011|isbn=978-0-321-27865-4}}</ref> [[behavior-driven development]] (BDD),<ref>Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, and Dan North. ''The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends.'' The Pragmatic Bookshelf.</ref> example-driven development (EDD),<ref>{{cite web| url = http://www.exampler.com/ | title = Example Driven Design| accessdate = 2013-04-15}}

</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.

Line 7:

==Overview==

Acceptance tests are from the user’s point of view – the external view of the system.<ref name="Pugh11" /> They examine externally visible effects, such as specifying the correct output of a system given a particular input. Acceptance tests can verify how the state of something changes, such as an order that goes from “paid” to “shipped”. They also can check the interactions with interfaces of other systems, such as shared databases or web services. In general, they are implementation independent, although automation of them may not be.<ref>Melnik, Grigori, and Frank Maurer. {{cite web | url = http://www.springerlink.com/content/34w2q2561k471175/ | title = Multiple Perspectives on Executable Acceptance Test-Driven Development | accessdate = 2013-04-15}}</ref><ref>Koskela, Lasse. (2007) Test Driven: TDD and Acceptance TDD for Java Developers. Manning Publications</ref>

===Creation===

Acceptance tests are created when the requirements are analyzed and prior to coding.<ref name="Pugh11" /> They can be developed collaboratively by requirement requester (product owner, business analyst, customer representative, etc.), developer, and tester. Developers implement the system using the acceptance tests. Failing tests provide quick feedback that the requirements are not being met. The tests are specified in business ___domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers.<ref>Evans, Eric. (2003) ''Domain-Driven Design: Tackling Complexity in the Heart of Software''. Addison-Wesley Professional.</ref> Tests and requirements are interrelated.

Acceptance tests are created when the requirements are analyzed and prior to coding.<ref name="Pugh11" /> They can be developed collaboratively by requirement requester (product owner, business analyst, customer representative, etc.), developer, and tester. Developers implement the system using the acceptance tests. Failing tests provide quick feedback that the requirements are not being met. The tests are specified in business ___domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers.<ref>Evans, Eric. (2003) ''Domain-Driven Design: Tackling Complexity in the Heart of Software''. Addison-Wesley Professional.</ref> Tests and requirements are interrelated.

<ref>{{cite book|last=Weinberg|first=Gerald|last2=Gause|first2=Donald|authorlink=Gerald_Weinberg|title=Exploring Requirements: Quality Before Design|publisher=Dorset House|year=1989|isbn= 0-932633-13-7}}</ref> A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement.<ref>Martin, Robert C., and Grigori Melnik.{{cite web | url = http://www.gmelnik.com/papers/IEEE_Software_Moebius_GMelnik_RMartin.pdf | title = Tests and Requirements, Requirements and Tests: A Möbius Strip | accessdate = 2013-04-15}}</ref>

===Testing Strategy===

Acceptance tests are a part of an overall testing strategy. They are the customer tests that demonstrate the business intent of a system. Component tests are technical acceptance tests developed by an architect that specify the behavior of large modules. Unit tests are created by the developer to drive easy-to-maintain code.<ref>[Test-driven_development]</ref> They are often derived from acceptance tests and unit tests. Cross-functional test include usability,<ref>Meszaros, Gerard, and Janice Aston. (2006) "Adding Usability Testing to an Agile Project."Agile Conference</ref> exploratory,<ref>{{cite web | title = Exploratory Testing Explained | url = http://www.satisfice.com/articles/et-article.pdf }}</ref> and property (scaling and security).<ref>Meszaros, Gerard.(2007) ''xUnit Test Patterns: Refactoring Test Code''. Addison-Wesley.</ref>

Line 46 ⟶ 43:

'''Given:'''

:Book that has not been checked out

{| class="wikitable"

|-

Line 59 ⟶ 54:

:User who is registered on the system

{| class="wikitable"

|-

Line 70 ⟶ 64:

'''When:'''

:User checks out a book

{| class="wikitable"

|-

Line 81 ⟶ 73:

'''Then:'''

:Book is marked as checked out

{| class="wikitable"

|-

Line 106 ⟶ 96:

'''Scenario:'''

Check that checkout business rule is enforced

'''Given:'''

:Book that has been checked out

{| class="wikitable"

|-

Line 133 ⟶ 120:

'''When:'''

:User checks out another book

{| class="wikitable"

|-

Line 144 ⟶ 129:

'''Then:'''

:Error occurs

{| class="wikitable"

|-

Line 156 ⟶ 139:

|}

=== Project acceptance tests ===

In addition to acceptance tests for requirements, acceptance tests can be used on a project as a whole.<ref name="Pugh11" /> For example, if this requirement was part of a library book checkout project, there could be acceptance tests for the whole project. These are often termed [[SMART criteria|SMART objectives]]. An example test is "When the new library system is in production, the users will be able to check books in and out three times as fast as they do today".

== See also ==

*[[Concordion]]

* [[ConcordionFitNesse]]

* [[FitNesseRobot Framework]]

* [[Robot Framework]]

== References ==