There is a cardinal mistake in the artcle about the TDD flow.
In TDD, we follow the steps below.
- Create the test case for testing each tiny bit of functionality.
- Run this test ( it will fail the first time as there is no code for this functionality.)
- Write only the code to pass the test cases.
- Run the test case again
- If the test case fails refractor the code to pass the test case
However, in TDD you *never* refactor to make a test pass! You should get the test to pass in the simplest way (sometimes even by "cheating" with a hardcoded result), and then refactor only while all test are passing. This makes sure you'r refactorings are always just "refactoring" (i.e. just changing the structure of the code without changing behaviour), while assuring that you *always* have code that works (even if it's still being refactored).
Nevertheless I was happy to see this article on SQLServerCentral, and especially glad to hear about the TSQL perspective. (I've been doing TSQL TDD manually for several months now, without any framework.. it's definitely hard but worthwhile. )