<slide_break></slide_break> ## 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?\] <slide_break></slide_break> ### 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 <slide_break></slide_break> ## 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 <slide_break></slide_break> ### 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) <slide_break></slide_break> ### 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