Last night I read the first chapter of Agile Principles, Patterns, and Practices in C#. Summary: Essentially, the Agile Manifesto, expounded.
This afternooon I just cracked open the introduction and Chapter 1 of Test-Driven Development in Microsoft .NET (Microsoft Professional). Summary: The basic, trivialized definition of TDD is 1) Never write code without starting with a breaking test, and 2) never repeat yourself. Test-driven development is apparently not about sitting around testing code like a QA engineer stuck in hell like I thought it would be. It's about writing code in tiny increments until each increment is working flawlessly, virtually eliminating the process of debugging. (Funny, that sounds very similar to a quote I saw after installing #develop a year or two ago. Something like: "The best way to write code is always to start with one small requirement, test it thoroughly, then add to it and repeat the process, until all requirements are complete.")
The section called "Red/Green/Refactor" is (I've seen this before, in a diagram in the Presenter First PDF from Atomic Object):
- Write the test code.
- Compile the test code. (It should fail because you haven't implemented anything yet.)
- Implement just enough to compile.
- Run the test and see it fail.
- Implement just enough to make the test pass.
- Run the test and see it pass.
- Refactor for clarity and to eliminate duplication.
- Repeat from the top.
This is an older book, a couple years, but still relevant. It focuses on NUnit which everyone is still using, although today I discovered MbUnit, which seems to have more features, but it's recommended by some to start with NUnit until you need some of MbUnit's extra features. I've also installed TestDriven.net but not sure what it offers yet.
Tonight before I get out of here (I'm stuck at the office and it's 10pm..) I am going to go through the Appendix A of this TDD book which is an NUnit primer.
Update: *click*. This happened to me when I realized that programmer tests are executed in bulk with a click of a button, and grow as your project grows, so if requirements change you can see what breaks from a tweak just by re-processing your programmer tests. No more manual trudging, no more "if it breaks, enter debug mode" start-to-finish manual tests. Those have to happen, too, but before they do you can quickly and easily see exactly where red flags are raised before you even get that far.
Subscribe