1. Copyright © 2006 Korson-Consulting 1/219 Unit 4 Test First Development

2. Copyright © 2006 Korson-Consulting 2/219 Test First Many programmers have adopted this approach with near religious zeal “Test-first design is infectious! Developers swear by it. We have yet to meet a developer who abandons test-first design after giving it an honest trial.” Robert C. Martin

3. Copyright © 2006 Korson-Consulting 3/219 The Process Write a test that specifies a tiny bit of functionality Compile the test and watch it fail (you haven't built the functionality yet!) Write only the code necessary to make the test pass Refactor the code, ensuring that it has the simplest design possible for the functionality built to date Repeat

4. Copyright © 2006 Korson-Consulting 4/219 The Philosophy Tests come first Test everything All unit tests run at 100% all the time

5. Copyright © 2006 Korson-Consulting 5/219 Implications Code is written so that modules are testable in isolation. –Code written without tests in mind is often highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll devise ways of minimizing dependencies in your system in order to write your tests. The tests act as documentation. –They are the first client of your classes; they show how the developer intended for the class to be used. The system has automated tests by definition. –As your system grows, running full regression tests manually will ultimately take outrageous amounts of time. Measurable progress is paced. –Tiny units of functionality are specified in the tests. Tiny means seconds to a few minutes. The code base progresses forward at a relatively constant rate in terms of the functionality supported.

6. Copyright © 2006 Korson-Consulting 6/219 Problems – Unit Testing Specifications are hidden in the tests Tests should not be the only documentation –Pre and post conditions should be explicit Test first development should be combined with programming by contract

7. Copyright © 2006 Korson-Consulting 7/219 The Improved Process Design the interface for the component Write a test that specifies a tiny bit of functionality Compile the test and watch it fail (you haven't built the functionality yet!) Write only the code necessary to make the test pass Refactor the code, ensuring that it has the simplest design possible for the functionality built to date Repeat

8. Copyright © 2006 Korson-Consulting 8/219 Extensions Test driven development focuses on unit testing –Increments could be defined by system level test cases System level test cases, for an increment, should be created by the test team before code is written for that increment –Ideally these test cases would be approved by the stakeholders

9. Copyright © 2006 Korson-Consulting 9/219 Getting the Code Right vs. Getting the Right Code Test first development ensures the code is doing what the developer intended it to do Acceptance testing can now focus on determining how well the developer’s intent matches client’s expectations

10. Copyright © 2006 Korson-Consulting 10/219 100% All unit tests run at 100% all the time We can’t require the same for acceptance tests, because then we’d be back to big bang integration So the rule for acceptance tests becomes –No integration is complete unless 100% of the previously passing acceptance test continue to pass.

11. Copyright © 2006 Korson-Consulting 11/219 Problems – Acceptance Testing Specifications are hidden in the tests Tests should not be the only documentation –Stakeholders will typically require a textual or tabular format for reviewing acceptance tests –Extreme XPers will resist having documentation outside of the executable code.

12. Copyright © 2006 Korson-Consulting 12/219 Automating System Tests at the GUI Level Capture and playback tools don’t work well in a quasi-agile environment –The scripts they generate are not easily maintained Choose a tool that has an API and write automated tests that call the tools interface –This can be overly time consuming compared to the risks it addresses Create automated tests that operate just below the user interface –Sounds scary, doesn’t it