Why Test?

• The mental habits needed to write tests parallel exactly those needed to design
• Insist on looking at the class/module/unit first as a black box that delivers services
• Good design delays all decisions that can be delayed until further requirements are nailed down.
• A good test suite can act as a detailed spec
• Testing and developing in parallel tends to surface more bugs early int development
• Tests demonstrate that your code actually works!
• A good test suite protects you from regressions
• Make refactoring possible and safe [how safe?]

Intro to Automated Testing

• Unit testing: test a small unit of code that has few side effects
• Integration testing: test a subsystem that has many components
• System testing: test the complete system from top to bottom
• Code Coverage: Seeing how much of your actual code is run during a test or production
• Performance testing: Checking the speed of your code

Can you test too much?

• Testing is not free!
• Tests have to be written, debugged and run
• Tests have to be maintained
• The code changes in two places: implementation and test
• Sometimes more: test fixtures, database schemas

What not to test

• Try not to test the same thing in more than one place
• Try not to test a library which is itself well tests
• Try not to test something that is self-evidently trivial (eye of the beholder)

What to test

• Try to test code which is prone to off-by-one errors
• Try to test code with intricate algorithms
• Try to test to verify assumption