Scott Tape said in the Slashdot Interview:
In my experience, programmers like to write code. Period. They don't like to write documentation, they don't like to write system tests, and they don't like to write unit tests. Programmers are also optimists--how else could they tackle building these enormously complex systems and think they had any chance of working? Programmers like instant gratification (who doesn't?). They enjoy coming up with a solution to a problem and seeing that solution implemented immediately.
Because programmers are optimists, that is reflected in their unit tests. Time and time again I've seen developer-written tests that demonstrate the feature works -- because the tests reflect the thinking of the developer about how the feature will be used. They rarely do a good job of testing corner cases, limits, or "unusual" situations (like running out of memory or other finite resources). </blockquote>
While all the remarks are good, the conclusion that programmers will not enjoy test first methodology is wrong. To my surprise, I have enjoyed it a lot. Here are some arguments :
- Programmers like to write code : programmers write even more code with test first methodology
- Programmers enjoy solving technical challenges : building a system so that it can be fully tested is a technical challenge wich makes the test system as interesting to write as the code for the sytem.
- Programmers enjoy instant gratification : having one's test run successfully is instant gratification and programmers enjoy it a lot. It may sound silly but I enjoy seeing myResult 37 / 37 successful test, 100% test pass. And I like seeing the number of test (== feature) moving forward. Means I am actually doing some measurable progress in my application
- writing tests is boring : it is boring if you write them once the application is ready. If you write them before your code, it gets interesting because it is equivalent to writing code. At some point, writing the test gets more interesting than the code, because the code "just runs the test, you know, not very exciting".
- corner case are not tested : in test first, it is recommended to test the corner case before the normal case. That way, they are a lot easier to deal with, and you are not tempted to skip them. Having plenty of tests already working also helps in building tests for corner cases. When it is just about calling 3 tests in a row and adding 10 lines of code, corner case testing is a lot more common.
- Geeks like to achieve good work : Having the system running many tests successfully is rewarding. You know that your system is fully working and tested. It will be easy to maintain and extend. If you modify it, just runs the tests to check that it is still working. This is really reassuring.