(1) Test Driven Development Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822

(2) What isn’t TDD? It is not a testing method. Typical goals of testing methods: Detect defects in software Assess the level of quality of a software implementation. Assess whether the software meets its requirements None of these are the primary motivation for TDD.

(3) What is TDD? It is a design method. The purpose of the tests in TDD is to drive the design of the system. You write a test before writing the code in order to clarify in your mind what the code should do when you write it.

(4) The basic TDD Cycle 0. Create an initial "To Do" List List of example test cases 1. Add a test Requires the developer to understand the specification and requirements clearly. May require use cases and/or user stories. 2. Run all tests and see the new one fail. Validates that test harness is working and that the new test does not already pass. The new test should fail for the expected reason.

(5) TDD Process 3. Write some code Implement just enough code to make the test pass. Try not to implement any functionality beyond what the test checks for. 4. Run the automated tests and see them succeed. If tests all pass, you can now Refactor code Tests can be re-run as necessary to ensure refactoring is not breaking code. Remove duplication whenever possible.

(6) The TDD To-Do List Contains: Examples of test cases Any refactorings that should be done Maintained continuously during development. The success or failure of TDD depends critically on your ability to create and maintain the ToDo list!

(7) A sample ToDo List for Stack Create a stack; verify isEmpty() is true. Push a single object onto Stack; verify isEmpty() is false. Push a single object, pop; verify isEmpty() is true. Push a single object, remember it, pop; verify the two objects are equal. Push three objects, remember them; pop and verify they are removed in correct order. Pop a Stack that has no elements; verify that an exception is thrown.

(8) The “rules” of TDD 1. Write new business code only when an automated test has failed. 2. Eliminate duplication when you see it. (Refactor)

(9) TDD outcomes Running code provides feedback to tests (and vice-versa). Developers write their own tests. Designs tend to be consist of cohesive, loosely coupled components.

(10) Properties of good unit tests They run fast. They run in isolation (no ordering dependencies) They use data that makes them easy to use and understand. They use real data whenever possible. They represent progress toward the solution. They provide documentation in the form of examples of how to invoke components of the system. They test "everything that could possibly break" They do not test things that cannot possibly break (setters, getters). They test the public interface. Not private methods/fields.

(11) “Pure” Unit Tests All "pure" unit tests for a system can be run many times a day as part of the TDD cycle. A test is not a “pure” unit test if: It talks to the database. It communicates across the network. It touches the file system. It can’t run at the same time as any of your other unit tests. You have to do special things to your environment (such as edit config files) to run it. "Impure unit tests" are extremely useful and necessary, but as the system scales, the time required to run them many times a day will start to slow down development.

(12) TDD Myths TDD always results in a regression test suite with 100% coverage for your entire application. Myth, because: You may be using an application framework or other third-party component. You may be working on a legacy system without tests. You may not have adequate tool support for TDD-driven database or UI design. You don’t need to test code that “can’t possibly break”. (getters, setters, constants)

(13) TDD Myths TDD satisfies all of your testing needs. Myth: TDD is a design technique, not a testing technique. You will still need acceptance tests, usability testing, etc.

(14) TDD Myths TDD automatically produces high quality code. Myth: An inexperienced developer using TDD can still produce low quality code. A development group may need code reviews or other mechanisms to ensure code quality.

(15) TDD Myths I can’t do TDD because I’m already started on the project. Myth: Just do it. You can begin doing TDD at any time.

(16) Conclusions TDD enjoys a high level of "religious fervor" at the current time. Much of the evidence supporting TDD is anecdotal. Even TDD advocates do not claim it is the best way to program in every situation. Nevertheless, for many situations, it appears to be a profound and important approach to designing and maintaining high quality software in an efficient manner.