Lecture Notes for Extreme Programming

26 June 2001 - Unit Testing


  1. testing has to be automated

  2. test everything that could possibly break

  3. correctly executing tests provide confidence and assurance

  4. the difference between unit tests and acceptance tests

  5. writing the tests

    1. write the tests first

    2. write the code to past the test

    3. write the tests bit by bit

  6. running fast tests

    1. running all tests all the time means tests should be fast

    2. if not, the tests or the code is slow and should be fixed

    3. tests should be simple

  7. writing hard tests

    1. difficulty writing tests indicates problems

    2. the code isn't understood

    3. the code is too complicated - high coupling

  8. test directly

    1. testing isn't transitive - code called by tested code isn't tested

    2. directly test all code

    3. greater certainty easier debugging

  9. when to stop testing

    1. a matter of skill, time, and energy

    2. test obvious things

    3. write a test that tickles discovered errors

  10. what about under-tested code

    1. organize tests around the parts being changed

  11. what about integration testing

    1. use the compiler

    2. structure the system to minimize and simplify coupling

  12. what about tough code - real time, multi-threaded, gui, database

    1. fake what's possible, simplify what can't be faked


This page last modified on 26 June 2001.