Acceptance tests and requirements are linked. You can’t have one without the other. The tests clarify and amplify the requirements. A test that fails shows that the system does not properly implement a requirement. A test that passes is a specification of how the system works.
Acceptance tests as described in this chapter are not the traditional user acceptance tests, which are performed after implementation “by the end user to determine if the system is working according to the specification in the contract.” They are also not system tests that are usually independently written by testers by reading the requirements to ensure that the system meets those requirements. However, all three types of tests are related in that they are all black-box tests; that is, they are independent of the implementation.
Acceptance Test–Driven Development is collaborating and improving our understanding through the development of acceptance tests. By having these conversations up front, we save a lot of rework later. Acceptance tests clarify understanding because they require both concepts (the requirement) and examples (the test specification). By actually implementing the test, we ensure our understanding as well increase our efficiency.
Tests for business logic can be executed in many ways.
* Creation through the user interface of a transaction that invokes the business rule
* Developing a user interface that invokes the business rule directly
* A test implemented in a language’s unit testing framework
* An automated test that communicates to the business rule module
Our experience has shown that ATDD is perhaps the most impactful practice that development teams can do. Much of the value is in the conversations and definitions of the tests – something that all teams do. Hence, we strongly recommend it as a practice to adopt as early as possible. The added cost is not much since it’s more about when you do your work, rather than adding new work.
Source: “Essential Skills for the Agile Developer – A Guide to Better Programming and Design”, Alan Shalloway, Scott Bain, Ken Pugh and Amir Kolsky, Addison-Wesley,
This quote discusses the important relationship between requirements and acceptance testing. I remember reading in another book that you cannot accept the definition of a requirement if it is not associated with some tests to make sure that the delivered software satisfies the requirement. This is why approaches like Acceptance Test–Driven Development (ATDD) and Behavior-Driven Development (BDD) try to create a definition of the requirements that can be directly interpreted by software testing tools.
RSpec Screen
Further reading
* Agile Acceptance Test-Driven Development: Requirements as Executable Tests
* Acceptance Test Driven Development (ATDD): an Overview
* Acceptance Test Driven Development (ATDD) Explained
* Acceptance Test Driven Development ATDD
* Benefits of Acceptance Test Driven Development
* Automated Acceptance Tests and Requirements Traceability
* “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning
Some Behavior-Driven Development (BDD) Tools:
* Cucumber is an open source behavior driven development (BDD) that works with Ruby, Java, .NET, Flex or web applications written in any language.
* NBehave is a framework for Behaviour-Driven Development for .NET
* JBehave is a framework for Behaviour-Driven Development (BDD) for Java
* RSpec is the original Behaviour Driven Development framework for Ruby.
Find a longer list of BDD tools on http://www.agilesoftwaretools.com/behaviordrivendevelopment.php
