Test-Driven Development “Test first, develop later!” –OCUnit

What is TDD? The conventional order of activities on a software project is to create test cases after the code has been written and you have something tangible to test. Traditional cycle of activities when programming: Design  Code  Test TDD puts the activity of writing unit tests in front of coding: Design  Test  Code The result is more than just a reordering of work. The new order of work changes the quality of work that is done. Writing tests before writing the code forces you to think about module design from the outside looking in rather than from the inside looking out. During design the most immediate concern isn’t how to write the code, but rather how to test the resulting code through its public interface. Design for implementation becomes a secondary concern.

TDD How To 1.Break requirements down into (very) small units of testable functionality. 2.Select a feature or small unit of functionality and write unit tests to test for the presents of the desired behavior 3.Test the tests. Run the new tests to verify they fail. If the tests don’t fail they are defective. 4.Write the code 5.Rerun the tests to verify that they now succeed 6.Refactor. Remove duplication and make other non- functional enhancements to the code. This step is driven by non-functional requirements 7.Repeat. Once cycle through these steps may take as little as 2 minutes [Professionalism and TDD, IEEE Software, Martin 2007]

Finer Points on the process of TDD 1.The new code you write doesn't have to be perfect. It only has to pass the tests. The refactor step at the end provides a chance to bring it up to standards. 2.You don't want to write any more code than necessary to pass the tests. This discipline helps guard against gold plating. 3.Tests should be automated and easy to run. The easier they are to run the more likely they will be. 4.Keep automated unit tests (test code) separate from production code. Production code is complex and fragile enough without mixing in additional test code. Reduce the chance of introducing a defect. 5.Unit tests should rely only on the public interface of the class or method tested. Messing with the internal state of an object tightly couples the test to the code which makes it harder to change the code in the future.

Three laws of TDD 1.You may not write production code unless you’ve first written a failing unit test. 2.You may not write more of a unit test than is sufficient to fail. 3.You may not write more production code than is sufficient to make the failing unit test pass. Source: [Martin IEEE Software]

Benefits TDD is a design technique as much as it is a testing technique. Design for testing leaves you with code that is more modular, more cohesive, and with a cleaner interface. Shortens the time between when a defect is injected and when it is detected. As soon as you write the code you have the test cases needed to test the code. If you force yourself to write the tests before writing the code you are guaranteed to have a nearly complete set of automated unit tests at the end of the coding phase. Having a large automated suite of tests gives you the confidence to make changes to the code without worrying that new code will break old code. Test cases document expected behavior of code. Programmers may prefer executable tests to written documentation. Automated test cases are executable documentation.

Limitations 1.It increases the amount of code that must be maintained. A small change in requirements can invalidate many unit tests. As a consequence, TDD tends to be more popular on green-field development projects. As the product ages it becomes harder to maintain existing tests. Failed tests may be abandoned rather than rewritten to accommodate new functionality. This can leave holes in the coverage. 2.Like many other coding practices that are of an investment nature (invest time/money now to save time/money later), this can be a tough sell if it’s your money you are investing now and someone else’s money that is saved later. It requires management support and the right incentive structure (e.g. charge back development for the cost of rework and maintenance).

Special Considerations You may need to refactor your first attempt or initial approach to design in order to accommodate TDD. Some applications are easier than others to apply the concept of TDD. GUI code is probably the most difficult as it's hard to test with code. One solution is to abstract functionality away from the GUI into a business logic layer and write automated tests on the business layer.

References Test-Driven Development by Example [Beck, K., Addison Wesley, 2003]. Many consider this to be the original source text on the concept Aim, Fire by Kent Beck, IEEE Software Sept/Oct Professionalism and Test-Driven Development, Martin, IEEE Software May/June 2007