Test-Driven Development

1
Test-Driven Development
Test first, develop later! OCUnit
2
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 isnt
  how to write the code, but rather how to test the
  resulting code through its public interface.
  Design for implementation becomes a secondary
  concern.

3
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 dont 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

4
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.

5
Three laws of TDD

• You may not write production code unless youve
  first written a failing unit test.
• You may not write more of a unit test than is
  sufficient to fail.
• You may not write more production code than is
  sufficient to make the failing unit test pass.
• Source Martin IEEE Software

6
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.

7
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
   its your money you are investing now and someone
   elses 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).

8
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. (Another
  reason business logic should be separate from UI.)

9
(No Transcript)
10
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
  2001.
• Professionalism and Test-Driven Development,
  Martin, IEEE Software May/June 2007