The good news is the big software vendors are ''finally'' supporting UnitTest''''''s with their IntegratedDevelopmentEnvironment''''''s

The other good news is their spin meisters are spreading enough disinformation that we SeagullConsultant''''''s don't need to fear for our jobs.

From elsewhere on the 'net:

	 :	What is TDD's Code-First Approach?
	 :	The code-first approach to TDD requires developers to follow these tasks:
		1. Thoroughly design your software. Know exactly what the software must accomplish before writing a single test.
		2. Use this design to create the interfaces and public methods for your objects (no implementation code).
		3. Use design requirements to build and execute tests, and watch them fail (Red).
		4. Write our implementation code and rerun our tests to watch them pass (Green).
		5. Interrogate the results and performance, tweak the code as necessary for structure, performance, ''etc.'' (Refactor).

	 :	Following this approach results in generation of a test suite, or logical grouping of automated unit tests that:
** Are based on functional and technical design requirements
** Are built up front, before implementation coding begins
** By  following  defined  naming  conventions  and standards, represent a structured and reference-able example of how to consume, deploy, and interact with your components

Where to start?

Firstly, this is BigTestUpFront, not TestDrivenDevelopment. The line "thoroughly design your software" implies someone has not yet learned the differences between hacking, BigDesignUpFront, and using tests to force a design to emerge.

After speculating about design, item 2 implies you write empty classes and methods. This is TopDownProgramming all over again. MS pitches this technique because it keeps their IntelliSense in play when you write your test. (Recall that under pure TestDrivenDevelopment, you should write the test first, and it should be so expressive and easy to write that you should not need IntelliSense.)

Line 3 implies you write many tests and fail them all.

Line 4 ... ah, screw it. The general picture here is refusing to "let go" of some favored security blankets.

At least this gets the kids writing more tests, so at least that's a GoodThing.

Right?

-- PhlIp

----

The article that inspired this page has been taken down and replaced with a note saying, "This topic is obsolete and has been removed from the MSDN documentation."

----

Lookit all the features we can sell in one page:
* Consider using the Class Designer (A code-generating (UML?) wizard in Visual Studio)
* Generate tests from your interfaces and classes. (Link to Visual Studio test generator wizard)
* Organize your tests into test lists (link to something in Visual Studio called a Test Manager)
* Run your tests (link to using the VisualStudio GUI test runner)

''So maybe it's working for its EarlyAdopter''''''s. If so, their debugging rate must be going way down. Does anyone know if it's working?''

----
CategoryAgileMethodology