After some feedback from Tony Rasa from http://www.elegantcode.com/ , I decided not to finish the book I started with. If I have not mentioned it before, I use Safari Books Online from O'reilly. This gives me instant access to over 2000 books from Microsoft, Apress, O'reilly, and others. I switched to "Test Driven Development by Example" by Kent Black. This book seems to be more inline with what I am looking for. It answered some of my questions right up front.
Warning: The examples in the book are in JAVA, but it often reads similiar to C#, you should pick it up with no problem.
Here is a piece I found interesting:
...following are two of the three strategies I know for quickly getting to green:
-
- Fake It— Return a constant and gradually replace constants with variables until you have the real code.
- Use Obvious Implementation— Type in the real implementation.
When I use TDD in practice, I commonly shift between these two modes of implementation. When everything is going smoothly and I know what to type, I put in Obvious Implementation after Obvious Implementation (running the tests each time to ensure that what's obvious to me is still obvious to the computer). As soon as I get an unexpected red bar, I back up, shift to faking implementations, and refactor to the right code. When my confidence returns, I go back to Obvious Implementations.
There is a third style of TDD, Triangulation, which we will demonstrate in Chapter 3. However, to review, we
-
- Translated a design objection (side effects) into a test case that failed because of the objection
- Got the code to compile quickly with a stub implementation
- Made the test work by typing in what seemed to be the right code
The translation of a feeling (for example, disgust at side effects) into a test (for example, multiply the same Dollar twice) is a common theme ofTDD. The longer I do this, the better able I am to translate my aesthetic judgments into tests. When I can do this, my design discussions become much more interesting. First we can talk about whether the system should work like this or like that. Once we decide on the correct behavior, we can talk about the best way of achieving that behavior. We can speculate about truth and beauty all we want over beers, but while we are programming we can leave airy-fairy discussions behind and talk cases.
This presented a great example on how to think about tests. I like all three of these ideas and will try to use them moving forward.
Code Happy,
Bill
Subscribe