Submitted Successfully!
To reward your contribution, here is a gift for you: A free trial for our video production service.
Thank you for your contribution! You can also upload a video entry or images related to this topic.
Version Summary Created by Modification Content Size Created at Operation
1 handwiki -- 909 2022-11-10 01:47:51

Video Upload Options

Do you have a full video?


Are you sure to Delete?
If you have any further questions, please contact Encyclopedia Editorial Office.
HandWiki. Acceptance Test–Driven Development. Encyclopedia. Available online: (accessed on 17 June 2024).
HandWiki. Acceptance Test–Driven Development. Encyclopedia. Available at: Accessed June 17, 2024.
HandWiki. "Acceptance Test–Driven Development" Encyclopedia, (accessed June 17, 2024).
HandWiki. (2022, November 10). Acceptance Test–Driven Development. In Encyclopedia.
HandWiki. "Acceptance Test–Driven Development." Encyclopedia. Web. 10 November, 2022.
Acceptance Test–Driven Development

Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE), behavior-driven development (BDD), example-driven development (EDD), and support-driven development also called story test–driven development (SDD). 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. ATDD is closely related to test-driven development (TDD). It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding.

development methodology acceptance tests acceptance

1. Overview

Acceptance tests are from the user's point of view – the external view of the system.[1] 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.[2][3]

1.1. Creation

Acceptance tests are created when the requirements are analyzed and prior to coding.[1] 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.[4] Tests and requirements are interrelated.[5] 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.[6]

1.2. 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.[7] They are often derived from acceptance tests and unit tests. Cross-functional testing includes usability testing,[8] exploratory testing,[9] and property testing (scaling and security).[10]

2. Acceptance Criteria and Tests

Acceptance criteria are a description of what would be checked by a test. Given a requirement such as "As a user, I want to check out a book from the library", an acceptance criterion might be, "verify the book is marked as checked out". An acceptance test for this requirement gives the details so that the test can be run with the same effect each time.

2.1. Test Format

Acceptance tests usually follow this form:[1]

Given (setup)

A specified state of a system

When (trigger)

An action or event occurs

Then (verification)

The state of the system has changed or an output has been produced

Also, it is possible to add Statements that start with AND in any of the sections below (Given, When, Then).

For the example requirement, the steps could be listed as:

Given Book that has not been checked out And User who is registered on the system When User checks out a book Then Book is marked as checked out

2.2. Complete Test

The previous steps do not include any specific example data, so that is added to complete the test:


Book that has not been checked out
Title Checked out
Great book No
User who is registered on the system
Name Sam


User checks out a book
Checkout action
User Sam Checks out Great book


Book is marked as checked out
Title Checked out User
Great book Yes Sam

2.3. Test Examination

Examination of the test with specific data usually leads to many questions. For the sample, these might be:

  • What if the book is already checked out?
  • What if the book does not exist?
  • What if the user is not registered on the system?
  • Is there a date that the book is due to be checked-in?
  • How many books can a user check out?

These questions help illuminate missing or ambiguous requirements. Additional details such as a due-date can be added to the expected result. Other acceptance tests can check that conditions such as attempting to check out a book that is already checked out produces the expected error.

2.4. Another Test Example

Suppose the business customer wanted a business rule that a user could only check out one book at a time. The following test would demonstrate that:

Scenario: Check that checkout business rule is enforced


Book that has been checked out
Title Checked out User
Great book Yes Sam
Another great book No


User checks out another book
Checkout action
User Sam Checks out Another great book


Error occurs
Error occurred
Violation of checkout business rule

2.5. Project Acceptance Tests

In addition to acceptance tests for requirements, acceptance tests can be used on a project as a whole.[1] 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 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".


  1. Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley. ISBN 978-0321714084. 
  2. Melnik, Grigori, and Frank Maurer. Melnik, Grigori; Maurer, Frank (2007). "Multiple Perspectives on Executable Acceptance Test-Driven Development". Agile Processes in Software Engineering and Extreme Programming. Lecture Notes in Computer Science. 4536. pp. 245–249. doi:10.1007/978-3-540-73101-6_46. ISBN 978-3-540-73100-9.
  3. Koskela, Lasse. (2007) Test Driven: TDD and Acceptance TDD for Java Developers. Manning Publications
  4. Evans, Eric. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.
  5. Weinberg, Gerald; Gause, Donald (1989). Exploring Requirements: Quality Before Design. Dorset House. ISBN 0-932633-13-7. 
  6. Martin, Robert C., and Grigori Melnik."Tests and Requirements, Requirements and Tests: A Möbius Strip". 
  7. [Test-driven_development]
  8. Meszaros, Gerard, and Janice Aston. (2006) "Adding Usability Testing to an Agile Project." Agile Conference
  9. "Exploratory Testing Explained". 
  10. Meszaros, Gerard.(2007) xUnit Test Patterns: Refactoring Test Code. Addison-Wesley.
Subjects: Business
Contributor MDPI registered users' name will be linked to their SciProfiles pages. To register with us, please refer to :
View Times: 468
Entry Collection: HandWiki
Revision: 1 time (View History)
Update Date: 16 Nov 2022
Video Production Service