These are his answers.
1. What kind of technique is TDD?
(a) It is a testing technique
(b) It is a design technique
(c) It is a learning technique
(d) It is an overall feature delivery technique
(e) More than one of the above applies
Answer: e. If you doubt that d is true, then see the very beginning of //c2.com/cgi/wiki?TestDrivenDevelopment
2. Which of these is necessary to do TDD?
(a) Write tests before production code
(d) Write failing tests, then pass them, one by one
(e) Refactoring
Answer: a, d, and e, but not b, c nor f
3. Which of the following activities does TDD replace?
(d) Debugging
Answer: only d, if you’re really good, but none of the rest
4. If we do TDD well, which of these statements is true about our code base?
(d) The cost of adding new behavior is relatively very low
(f) We feel confident in maintaining it indefinitely
Answer: very probably d and f, but the other statements are far too absolute to be true in general. We probably have very high code coverage. We probably have very little duplication and very clear code in the part of the code base that has changed the most. We probably have very few defects and defects arrive at rate that depends on the age of the code base, rather than its size.
Enjoy.
I agree with JB that you should first read the wiki article on C2. IT’s the basic of a lot in XP if not agile. (if you did not know C2 is the first public wiki)
Here are some more links
On Wikipedia: //en.wikipedia.org/wiki/Test-driven_development
Next you can read anything that Brian Marick wrote in TDD
I don’t always agree with Scott Ambler: but this post seems like a nice one on TDD
If that is not enough, check out these books:
Michael Feathers classical book is not technical about TDD, but his idea’s can help you prepare your code so you can start doing TDD
Of course JB’s book. It’s not purely about TDD, but it helps if you are a java developer.
If you had a doubt if answer 2 E was right, check out Agile in a Flash about TDD. JB used here refactoring the way we use it in agile. Not the way some companies call “large 3 years rework”, refactoring.