Editing Test-driven development (section)

===Keep the unit small===
For TDD, a unit is most commonly defined as a class, or a group of related functions often called a module. Keeping units relatively small is claimed to provide critical benefits, including:
* Reduced debugging effort – When test failures are detected, having smaller units aids in tracking down errors. 
* Self-documenting tests – Small test cases are easier to read and to understand.<ref name="Pathfinder Solutions" />

Advanced practices of test-driven development can lead to [[acceptance test–driven development]] (ATDD) and [[specification by example]] where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process.<ref name="Koskela">Koskela, L. "Test Driven: TDD and Acceptance TDD for Java Developers", Manning Publications, 2007</ref> This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. With ATDD, the development team now has a specific target to satisfy – the acceptance tests – which keeps them continuously focused on what the customer really wants from each user story.