--- title: "Test-First vs. Implementation-First : What Microsoft really meant" url: "https://osherove.com/blog/2005/11/24/test-first-vs-implementation-first-what-microsoft-really-mea.md" canonical: "https://osherove.com/blog/2005/11/24/test-first-vs-implementation-first-what-microsoft-really-mea.html" published: "2005-11-24T22:03:00" updated: "2005-11-24T22:03:00" tags: ["Agile Related"] author: "Roy Osherove" description: "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…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Test-First vs. Implementation-First : What Microsoft really meant By Roy Osherove November 24, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published November 24, 2005; technical details may be outdated. The following diagram is borrowed from [Scott Dockendorf's blog](http://weblogs.asp.net/scottdockendorf/), where he [explains an article he's written about unit testing with VS 2005](http://weblogs.asp.net/scottdockendorf/archive/2005/01/25/360485.aspx)(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](http://weblogs.asp.net/rosherove/archive/2005/11/23/431341.aspx) 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. ## More in Agile Related [All posts in Agile Related](https://osherove.com/blog/category/agile-related) - Nov 28, 2005 ### [Agile Israel meets today! The Planning Game](https://osherove.com/blog/2005/11/28/agile-israel-meets-today-the-planning-game.html) - Nov 26, 2005 ### [Nice article on ordering code construction tasks by Jeremy Miller](https://osherove.com/blog/2005/11/26/nice-article-on-ordering-code-construction-tasks-by-jeremy-m.html) - Nov 23, 2005 ### [Webcast: Agile and eXtreme Programming from patterns & practices (Level 200)](https://osherove.com/blog/2005/11/23/webcast-agile-and-extreme-programming-from-patterns-amp-prac.html) - Nov 23, 2005 ### [Microsoft fails miserably to explain or promote Test Driven Development in Team System](https://osherove.com/blog/2005/11/23/microsoft-fails-miserably-to-explain-or-promote-test-driven.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/