Lean-Agile Acceptance Test-Driven Development. Better Software Through Collaboration - Pugh K. - 2011

Although acceptance testing has been around for a long time, it was reinvigorated by extreme programming. Its manifestations include ATDD as described in this book, example-driven development (EDD) by Brian Marick, behavior-driven development (BDD) by Dan North, story test-driven development (SDD) by Joshua Kerievsky of Industrial Logic, domain-driven design (DDD) by Eric Evans, and executable acceptance test-driven development (EATDD)

Tests for business rules can be executed in at least these four ways:

• Creation through the user interface of a transaction that invokes the business rule
• Development of a user interface that directly invokes the business rule 
• A unit test implemented in a language’s unit testing framework
• An automated test that communicates with the business rule module

• The structure of a test is 
• Given <setup> 
• When <action or event> 
• Then <expected results>
• For calculation tests, the structure is 
• Given <input> 
• When <computation occurs> 
• Then <expected results> 
• Following are three types of tables: 
• Calculation—Gives result for particular input 
• Data—Gives data that should exist (or be created if necessary) 
• Action—Performs some action

• Create a test for each exception and alternative in a use case. 
• Do not automate everything. 
• Run tests at multiple levels. 
• Create a working system early to check against objectives.

• When creating and implementing tests, consider the following: 
• Develop tests and automation separately. Understand the test first, and then explore how to automate it.
• Automate the tests so that they can be part of a continuous build.
• Don’t put test logic in the production code. Tests should be completely separate from the production code. 
• As much as practical, cover 100% of the functional requirements in the acceptance tests.

In structuring tests, remember the following:

• Tests should follow the Given-When-Then or the Arrange-Act-Assert.
• Keep tests simple. 
• Only have the essential detail in a test. 
• Avoid lots of input and output columns. Break large tables into smaller ones, or show common values in the headers.
• Avoid logic in tests. 
• Describe the intent of the test, not just a series of steps.

• Equivalence partitioning, which divides inputs into groups that should exhibit similar behavior.
• Boundary value analysis, which tests values at the edge of each equivalence partition.
• State transition testing checks the response from a system that depends on its state. 
• Use case testing to check all paths through a use case. 
• Decision table testing for complex business rules.  Often, the decision table is presented in the opposite format, where rows and columns are interchanged from the format used in this book. 

• Who—The triad—customer, developer, and tester communicating and
• collaborating
• What—Acceptance criteria for projects and features, acceptance tests for
• stories
• When—Prior to implementation—either in the iteration before or up to
• one second before, depending on your environment
• Where—Created in a joint meeting, run as part of the build process
• Why—To effectively build high-quality software and to cut down the
• amount of rework
• How—In face-to-face discussions, using Given/When/Then and examples

Framework Websites

JBehave http://jbehave.org/
Fit http://fit.c2.com/
FitNesse http://fitnesse.org/
Easyb http://www.easyb.org/
Cucumber http://cukes.info
Robot http://code.google.com/p/robotframework/
Arbiter http://arbiter.sourceforge.net/
Concordian http://www.concordion.org/
Selenium http://seleniumhq.org
Watir http://watir.com/

Other frameworks at: http://www.opensourcetesting.org/functional.php


http://www.acceptancetestdrivendevelopment.com/