Test-First vs. Implementation-First : What Microsoft really meant

The following diagram is borrowed from Scott Dockendorf's blog, where he explains an article he's written about unit testing with VS 2005(a different article than the one posted on MSDN). It explains clearly the difference between the approach Microsoft is enabling (as in the now infamous article) for Unit Test related work and the approach of Test Driven Development. Even though he's talking about a whole different article that the one I discussed in previous posts, it does explain the difference in approaches so clearly that I had to borrow it here.  

 

	Approach #1:  Test-First	Approach #2: Code/Interface First
Description:	Born from Extreme Programming methodology, was the initial implementation.  This is the traditional approach	Evolved after birth of Test-First, where Interfaces are created before the tests
Where does the “Design” occur	During TDD cycle	Up-front, when designing the solution.
Steps:	Design Code your Tests Run Your Test – (.NET Compiler won’t let you continue, because you’re referencing objects that don’t exist yet Fix Compile Errors by creating object with public interfaces (as defined in your test) Rerun Test – Watch them fail “Red” Complete Implementation Code Rerun Tests – Watch them pass Review Code / Refactor as necessary Go Onto The Next Test	Design Code your Interfaces based on your design Code your Tests Run Test – Watch them fail “Red” Complete Implementation Code Rerun Tests – Watch them pass Review Code / Refactor as necessary

 

Clearly, Microsoft's approach in their (now expired) article on so called "Test Driven Development" landed squarely in approach #2 while the blogsphere (myself included) was shouting that Microsoft mistakenly calls it "Test-First" (a.k.a approach #1).

Scott's article on the subject is probably what the Microsoft article wished it could be, with all the clarifications by Scott attached at the bottom.