Test Driven Development is a key agile practice. In fact, it is one of the most profound practices of agile development. TDD offers a different way to program---a way that helps you keep track of where you are in the problem solving process and helps you avoid long debugging sessions. The TDD approach can provide a great advantage to embedded developers.

Test Driven Development is an technique for building software incrementally. No production code is written without first writing a failing unit test. Tests are small. Tests are automated. They work well with how humans work.

Instead of diving into the production code, leaving test for later; the TDD practitioner expresses the desired outcome in a test. The test fails. It may not even compile. Only then do they write the code, making the test pass.

Each step of the way, new automated unit tests are written followed immediately by code satisfying those tests. As the production code grows, so does a valuable suite of unit tests. With every code change the test suite runs, checking the new code's function but also checking all existing code for compatibility with the latest change. The tests provide assurance that the code, old and new, does what is expected.

Test Driven Development is not a testing technique, although you do end up with a lot of valuable automated tests. It is a way to solve programming problems. It helps software developers make good design decisions.

Test Driven Development is a powerful technique for building embedded software.

Let's compare TDD to the traditional way of programming, something I like to call Debug Later Programming. In DLP, code is designed and written prior to tests; when the code is "done" it is tested. We all know that mistakes are made during design and coding. The problem with debug later programming is that the feedback revealing those mistakes may take days, weeks or months. By then we have lost the context of the problem we were solving when the defect was introduced and the debugging starts. This inherently unpredictable activity can destroy the most carefully crafted plans. In comparison, with TDD we get immediate feedback of many of the mistakes made during design and coding. This immediate notification can help to avoid many of those unplanned and unpredictable debug sessions.

When we're writing code we follow a repeating cycle of small steps known as the TDD Microcycle. Each pass through the cycle provides feedback that our new and old code behaves as expected because it passes our tests. I've embellished Kent Beck's description of the TDD cycle in the following list.

1. Add a small test
2. Run all the tests and see the new one fail, maybe not even compile
3. Make the small changes needed to pass the test
4. Run all the tests and see the new one pass
5. Refactor to remove duplication and improve expressiveness.

Each spin through the TDD cycle is designed to take only a few minutes. New tests and code are added incrementally with immediate feedback showing that the code just written actually does what it is supposed to do. We grow the system modules from simple roots to more complex behavior, learning more about the problem and the solution as we go. The tests and code capture our knowledge of the problem and our solution.

Running the tests with every change shows us if our recent change broke anything that used to work. In a sense, our code tells us when we break it! TDD can't work without automated tests. Tests have to be cheap to run and manual tests are expensive and error prone.