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:

  1. Design
  2. Code your Tests
  3. Run Your Test – (.NET Compiler won’t let you continue, because you’re referencing objects that don’t exist yet
  4. Fix Compile Errors by creating object with public interfaces (as defined in your test)
  5. Rerun Test – Watch them fail “Red”
  6. Complete Implementation Code
  7. Rerun Tests – Watch them pass
  8. Review Code / Refactor as necessary
  9. Go Onto The Next Test
  1. Design
  2. Code your Interfaces based on your design
  3. Code your Tests
  4. Run Test – Watch them fail “Red”
  5. Complete Implementation Code
  6. Rerun Tests – Watch them pass
  7. 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.