ExcusesForNotDoingTfd

I'm giving a talk about TFD at <large-anonymous-company>. I'd like to put up a slide with a few of the major excuses for not doing TFD, so that I can address them directly. --DafyddRees

The excuses list so far:

• "I don't have time to do TFD"''"...because I have so many bugs to chase down."''?
• "I don't know how to test that." ''Read Kent's new book, and find out about MockObjects''?
• "You can't capture every kind of bug with automated unit testing." ''So what _are_ you going to do instead?''?
• "Good programmers don't need tests."
• please feel free to add excuses

Here are some that I struggle with:

• I am interfacing to legacy code/hardware who's behaviour is too complex to mock (except in the sense of 'poke fun at')
• • OliBye has this problem, he wraps only the functionality he wants from the library into an interface. Then has a EasyMock? implementation that checks you make the right calls, and a which does straight through delegation to the real library. You can test the wrapper in functional tests. We tend not to have unit tests for the wrapper as you tend to simply be testing you can make method calls.
  • OliBye then tends to build the ObjectModel? that he really wants ontop of this wrapper. This usually handles errors etc. The behaviour of your application code can then be tested in exceptional conditions, e.g. time going backwards in autumn, or nasty database errors that are hard to actually generate, but simple to get EasyMock? to through.

• I am writing code for graphical output (HowDoYouWriteUnitTestsFor a Mandelbrot generator or 3D graphics library?)
• • NatPryce has been writing a game using TFD to experiment in how far you can test graphical output. He has managed to test rendering 3D sprites in an isometric projection with dirty rectangle caching, masked blits (to implement bi-level alpha channels), and double buffering. He did this by mocking up those parts of the PyGtk? and PyGnome? libraries necessary for testing low level drawing routines. (Note: Python makes this easy because you can write MockObjects that mock the behaviour of entire modules). He found that forcing yourself to write in a test-first manner often requires that you write it in a way that is different to how you learnt to write graphics and GUI code, but that this is a good thing.

-- DaveKirby