Dig the well before you are thirsty.

–Chinese Proverb

 

Test-First Development Abstract

Test-first is a cornerstone of XP and should be a mainstay of all Agile methods, including Scrum and Kanban. Originally called test-first programming, larger scale development has required more than just the programming of tests first. The key to test-first development is understanding the intention of what you are writing before you write it. There are two main levels of test-first:

  • Acceptance Test-Driven Development

The method of doing these tests fall under the umbrella of what we call Sustainable Test-Driven Development. Test-First development is based on several principles. Two of the most important is that testability, that is, how easily testable code is, is related to code quality. Testability is one of the best software trim tabs to attend to. Another critical reason is that test-first follows one of the mantras of good design mandated by design patterns – design to interfaces. This is topic is also discussed in [1].

Details

Acceptance Test-Driven-Development (ATDD) is mostly about having the people playing the product owner (customer proxy), developer and tester roles discussing the requirements before writing code. The intention is to create a series of acceptance tests that, when passed successfully, will demonstrate the working of the system. ATDD is more about the clarity that occurs with this conversation. However, the resulting test-specifications can provide the basis for automated regression testing – a very useful practice for quick deliveries. These tests can be in the form of tables or in the form of “in this situation, when this event occurs, this result occurs.” Be clear that the result of ATDD is defined and implemented acceptance tests for the system – not mere specifications that describe scenarios that need to be handled. See [2] for more.

Test-Driven Development, on the other hand is a developer-oriented activity designed to assist the developers in writing the code by strict analysis of the requirements and the establishment of functional boundaries, work-flows, significant values, and initial states. TDD tests are written in the developer’s language and are not designed to be read by the customers. These tests can use the public interfaces of the system, but are also used to test internal design elements. We often see the developers take the tests written through the ATDD process and implement them with a unit testing framework.

Learn More

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[1] Shalloway, A., Bain, S., Pugh, K., & Kolsky, A. Essential Skills for the Agile Developer: A Guide to Better Programming and Design. Addison-Wesley, 2011.

[2] Pugh, Ken. Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley, 2011.

 

Last updated 15 January 2013

© 2010-2013 Leffingwell, LLC.