Test-driven development (TDD) is a way to write source code that involves writing an automated unit-level test case that fails, then writing just enough code to make the test pass, then refactoring both the test code and the production code, then repeating with another new test case. Alternative approaches to writing automated tests is to write all of the production code before starting on the test code or to write all of the test code before starting on the production code. With TDD, both are written together, therefore shortening debugging time needs. TDD is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right. Programmers also apply the concept to improving and debugging legacy code developed with older methods.
History Software engineer Kent Beck, who is credited with having developed or "rediscovered" the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I'd written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, "Of course. How else could you program?" Therefore I refer to my role as "rediscovering" TDD.
Coding cycle
The TDD steps vary somewhat by author in count and description, but are generally as follows. These are based on the book Test-Driven Development by Example, and Kent Beck's Canon TDD article.
1. List scenarios for the new feature List the expected variants in the new behavior. "There's the basic case & then what-if this service times out & what-if the key isn't in the database yet &…" The developer can discover these specifications by asking about use cases and user stories. A key benefit of TDD is that it makes the developer focus on requirements before writing code. This is in contrast with the usual practice, where unit tests are only written after code. 2. Write a test for an item on the list Write an automated test that would pass if the variant in the new behavior is met. 3. Run all tests. The new test should fail – for expected reasons This shows that new code is actually needed for the desired feature. It validates that the test harness is working correctly. It rules out the possibility that the new test is flawed and will always pass. 4. Write the simplest code that passes the new test Inelegant code and hard coding is acceptable. The code will be honed in Step 6. No code should be added beyond the tested functions. 5. All tests should now pass If any fail, fix failing tests with minimal changes until all pass. 6. Refactor as needed while ensuring all tests continue to pass Code is refactored for readability and maintainability. In particular, hard-coded test data should be removed from the production code. Running the test suite after each refactor ensures that no existing function is broken. Examples of refactoring: moving code to where it most logically belongs removing duplicate code making names self-documenting splitting methods into smaller pieces re-arranging inheritance hierarchies Repeat Repeat the process, starting at step 2, with each test on the list until all tests are implemented and passing. Each tests should be small and commits made often. If new code fails some tests, the programmer can undo or revert rather than debug excessively. When using external libraries, it is important not to write tests that are so small as to effectively test that library only, unless there is reason to believe that the library is buggy or too feature-poor to serve all needs of the software under development.
Test-driven work TDD has been adopted outside of software development, in both product and service teams, as test-driven work. For testing to be successful, it needs to be practiced at the micro and macro levels. Every method in a class, every input data value, log message, and error code, amongst other data points, need to be tested. Similar to TDD, non-software teams develop quality control (QC) checks (usually manual tests rather than automated tests) for each aspect of the work prior to commencing. These QC checks are then used to inform the design and validate the associated outcomes. The six steps of the TDD sequence are applied with minor semantic changes:
"Add a check" replaces "Add a test" "Run all checks" replaces "Run all tests" "Do the work" replaces "Write some code" "Run all checks" replaces "Run tests" "Clean up the work" replaces "Refactor code" "Repeat"
… excerpt ends here. Continue reading the full article.
