Getting started with test-driven development

There are several names by which a test-first approach is known: test-first development, test-driven development, and acceptance test-driven development, among others. No matter the nomenclature, test-driven development is the method in which a developer writes the tests before writing the code.

Applying Red, Green, Refactor methodology

The Red-Green-Refactor cycle is a long-standing practice in software development. The general practice includes three steps.

1. Create a unit test that fails.

2. Write production code that will pass that test.

3. Clean up the mess you just made.

First, a test is written to check for potential failure. Next, only a minimal amount of code is created—enough to have the test pass. The developer proceeds to revise the test to fail against new code that will be included to meet business requirements. Then, code is written to pass the test. If the test does not pass, then update the code or the test until it does.

The test-first approach offers many advantages that improve the development process, such as:

• Developers can use the method to build high confidence in the test suite with up-front, immediate feedback on the functional and structural quality of the system.

• Writing a test in small, incremental iterations provides frequent, instantaneous feedback minimizes both time and effort in fixing design or implementation flaws. (See Martin Fowler on the Developer Feedback Loop.)

• Confidence in quality quickly rises and remains high during the entire effort.
  Since there is no risk of a regression failure, the increased confidence further motivates developers to refactor or write new code.

• Developers have plenty of freedom and incentive to write clean code. Subsequently, there remains no need for extensive manual testing.

• There is no significant increase in the net overall effort, yet there is continuous incentive to pursue incremental improvements.

• System design, test-based specification of the system, and descriptive accuracy of tests improve.

Writing the test first drives developers to focus on behavior expectations. The method ensures that both the tests and code are driven primarily by business requirements. If all requirements are met, and all tests pass in tandem with the new code changes, then there is maximum confidence that all known test cases have been written.

Test-first vs. test-late

Yes, it’s possible to eventually write good test suites with either approach. However, the test-first approach offers many clear benefits, while the test-late approach commonly produces a test suite that can only provide a fraction of those benefits.

TEST-FIRST: Test-driven development that focuses on the most important elements of the application. Software is built for users with development managers incentivized to ensure compliance with business requirements.

TEST-LATE: Testers have to discern how best to focus the testing and how much effort to expend on the testing. The major risk is that the testing will be insufficient (i.e., tests likely aren’t adequately descriptive, with the team wasting effort automating test cases for the incorrect module boundaries).