Lecture Notes for Extreme Programming
26 June 2001 - Unit Testing
- testing has to be automated
- test everything that could possibly break
- correctly executing tests provide confidence and assurance
- the difference between unit tests and acceptance tests
- writing the tests
- write the tests first
- write the code to past the test
- write the tests bit by bit
- running fast tests
- running all tests all the time means tests should be fast
- if not, the tests or the code is slow and should be fixed
- tests should be simple
- writing hard tests
- difficulty writing tests indicates problems
- the code isn't understood
- the code is too complicated - high coupling
- test directly
- testing isn't transitive - code called by tested code isn't tested
- directly test all code
- greater certainty easier debugging
- when to stop testing
- a matter of skill, time, and energy
- test obvious things
- write a test that tickles discovered errors
- what about under-tested code
- organize tests around the parts being changed
- what about integration testing
- use the compiler
- structure the system to minimize and simplify coupling
- what about tough code - real time, multi-threaded, gui, database
- fake what's possible, simplify what can't be faked
This page last modified on 26 June 2001.