I have to admit that as much as I have done Test Driven Development, I have not read Kent Beck’s book all the way through. It certainly has not hindered me, but since I have the book to give away at an upcoming WeProgram.NET meeting on TDD, I figured I’d breeze through it in a couple of hours. Here are my notes, in case anyone finds them useful.
Notes from Test Driven Development: By Example, Kent Beck
- There are three methods of going forward when doing TDD: fake it, use an obvious implementation, and triangulation.
- Fake it is where you just return the exact value you need. If your test expects a zero from a method, use a “return 0;” statement. Usually you use this when you cannot tell how to implement certain functionality, or your previous steps were too large and you cannot figure out what went wrong. Something that works is better than something that doesn’t work!
- Use obvious implementation when you are pretty sure of the code you need to write, so write it and see if the test passes. The majority of the time you will use this method to move forward with TDD quickly.
- Triangulation is where you want to generalize a certain behavior, but are not sure how to do it. So you start with fake it and add additional tests that force the code to be more generic along a certain dimension. This is how you test the code’s axes of variance (measure some code’s resilience to change along a specified dimension). For example, to test the money code’s axis of variance for different currencies, Kent added tests for Francs in addition to Dollars.
- If you inherit code without unit tests, retroactively setup unit tests for the section of code you are working to make sure you don’t introduce any new bugs with your bug fix. Do not attempt to setup unit tests for the entire application.
- Test Driven Development keeps the developer working at the fastest speed possible for the current conditions. Is the step size feeling too restrictive? Use obvious implementation to take bigger steps and accomplish more with each run of the unit tests suite. Are you getting surprised by red bars? Slow down and try faking it or triangulation and run the test suite more often.
- Keep a test list. This list should contain three categories of items: new code, refactorings, and new tests. For example, if you think about an extension point (new code) for the code you are working on, write it down but keep working on what you are doing at this instant. Focus is the key.
- A common mistake is to write tests that pass after the code is written. Don’t do this. Although Kent gives one, rather philosophical reason, my reason is that if it hasn’t failed, you haven’t proved the test works. The test should fail, you should add or change some code, and then the test should pass. This (almost) ensures that the code works and it works the way you think it works.
