Last week I started ATQ. Instead of me inventing all questions I asked some agile friends. This week JB Rainsberger gave me questions for TDD. (Which is cool as today we have XPDays Benelux and JB is here…)
(If you too have one or more ideas for another ATQ, please contact me)
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
F) None of the above
2. Which of these is necessary to do TDD?
A) Write tests before production code
B) Decide all the tests you plan to write before writing them
C) Make all design decisions after you start writing code
D) Write failing tests, then pass them, one by one
E) Refactoring
F) Apply Design Patterns
3. Which of the following activities does TDD replace?
A) Design sessions, such as whiteboarding, CRC, architecture debates
B) Manual testing by skilled testers
C) Manual test plan execution
D) Debugging
E) Automated system testing
F) Documenting APIs we intend to publish
4. If we do TDD well, which of these statements is true about our code base?
A) We have 100% code coverage
B) We have no duplicate code
C) Our code is crystal clear
D) The cost of adding new behavior is relatively very low
E) We have no defects
F) We feel confident in maintaining it indefinitely
4 comments on “Agile Thursday Quiz: TDD”
Let’s give it a try.
1) the more I think about it the more uncertaint I become what the appropriate answer is. It enforces a certain design but does that make TDD a design technique?
I’ll go for A and D (and therefore E as well)
2) A, D, E, and possibly B
3) none?!
It will reduce the number of searching errors by debugging compared to writing code without tests, but I don’t think it replaces it. It is also said that well written tests replace documentation. (I definietly have to work on that part) But does that really _replace_ (API) documentation?
4) B, C, D, F
not sure about A. Do the costs for achieving 100% code coverage justify the costs?
OK let’s do it ! 🙂
1) B and often C, so E :). A isn’t about TDD, it’s about running the tests often. you can test cithout doing TDD
2) the way I understand the answers : A, D, E. F isn’t always necessary, but quite often you need patterns for refactoring purpose. I hesitate…
3) C and D for a big part.
4) B, C, D, F. About A, I think it’s true, but what is not true is about having completed 100% of cases (ie complexity)
OK. I’ll say:
EADD
It’s tricky but that represents my current understanding of TDD.