Benjaminblogs about Jim Newkirk's excellent talk on Test Driven Development this past week at TechEd. In particular, Jim talked about his use of the new unit testing features of the Visual Studio 2005 Team System.
The most interesting items, which Benjamin summarizes, are these:
The Two Tenets of Test Driven Development:
- Never write a single line of code unless you have a failing unit test. The goal is to take requirements and express them as test
- Eliminate duplication
How to do TDD
Jim starts by blocking out 4 - 8 hour sessions of development. He spends 15 - 20 minutes at the start of each session thinking about what he is going to do and brainstorming a list of unit tests.A key part is not to get hung up on completeness, you can always add more later. The purpose of the tests is to describe completion requirements.
The flow of a TDD session: Red, Green, Refactor
The process is:
- Start by writing a test for a new capability
- Compile
- Fix any compile errors
- Run the test and see it fail
- Write the code to make the test pass
- Refactor as needed (clean up any duplication)
The purpose is about how to use the functionality, not how to implement it! The process allows you to build confidence through having a set of tests that pass.
The most successful way to do test is to do it before the development. If you start it first then you need to think about how to test.
It's always good to have a quick refresher of basic TDD operation and thinking.
One of the coolest things about the new unit testing sysem is this:
... writing a class name followed by a method name that didn't exist yet. After compiling, Jim used a 'smart tag' to choose to create the method stub inside the target class. It wrote this stub and had a 'NotImplementedException' inside it. This is functionality similar to Eclipse and is good to see.
That's great! This can only help .Net developers use TDD more by following the “write the tests first” rule. Very exciting!
