WhenTestFirstGetsHard

XP and agile practices both encourage Wiki:TestFirstDesign and Wiki:TestDrivenProgramming (or is that test-first programming and test-driven design? :). When does this advice get hard to follow? What solutions have people found?

Problems For Test First

• Sockets
• Threads
• Tests involving large datasets
• Interacting with hardware
• GUI
• Code embedded in a web page / mixed languages
• Legacy code without tests

Some Known Solutions

• Wiki:MockObjects
• Break the problem into smaller chunks
  • you have something larger than a unit test
  • test every hop in a chain
  • start early!
• Wiki:ObjectMother
  • refactor setup code into an object
• Something is better than nothing
  • Automated GUI tools (WinRunner?, etc)
    • difficult when you make changes (small change in gui requires test script to be rewritten)
  • Acceptance tests first (before unit tests)
    • good for legacy code without tests
• For Large Data:
  • Golden Copy that gets copied to test database
  • Extra bit to detect changed data (so database is only reloaded if necessary)
  • Mock objects impersonating the database
• For multithreaded issues:
  • write success path test, write the code, then write tests to expose expected bugs.
    • test driven design does not imply that all tests have to be written before the code can be designed
  • Stress tests (better than nothing)
• Always remember that some or any tests are better than no tests

How do you teach Test-First?

• Pairing with a coach - seems to be one of the few truly effective ways
• Mandatory test-first
  • encourages pairing with the coach (when programmers find they don't know how to do test-first)
• Persistence of test results
  • can prove that a failing test existed first
  • allows enforcement of manadatory test-first

Wiki:TestingTools