I have followed all four of Andy's articles in the "An Example of Test-Driven Development" series. I don't know if he plans more. Look under the tag "Test-Driven Development" and you'll see only a few articles so far, but Andy's series is a nice addition to this topic.
The title is apt--he offers "An Example" (nothing more, nothing less) that from my take offers a clean look into how Andy approaches database TDD start-to-finish from setting up a project/solution in SSMS, organizing the code into the Queries folder to deployment-- with lots for us to consider and learn from.
This is the kind of material that I find valuable--having a look at how other professionals do things from someone who is willing to open up rather than making their solutions "closely-guarded secrets" and who is willing to expose themselves to the inevitable criticism of exposure.
Here are some questions I think are worth pursuing from the series thus far:
1. Article 3 offers an example of automating the creation of scripts that test for the existence of database objects like tables and stored procedures. But the article is light on the discussion of why and to what extent one would want to do that--which is fine. That's what these discussion posts are for.
I think in the world of RDBMS and database development, the test-driven development technique/decision of "test before coding" can be considered optional and subject to project-specific considerations.
Andy's solution of automating the creation of test scripts gives the developer the option of using a "first create an object, then immediately after, create the existence test" technique with the understood risks taken.
Before a TDD purist attacks this proposition, take in mind that we're on the cusp of developers (and other less-technical stakeholders) using Oslo and MSchema which expresses T-SQL code, putting the creation first in a fluid development environment where frequent initial changes to objects will take place as entities and relationships are hammered out. So, I think the road ahead favors the agility of "create the existence tests immediately after" technique.
2. Existence tests have been discussed--which begs the question of to what level of detail we should test for. How about test for the table columns with their data types, default values, nullability, and so forth? There's a good bit of complexity once we move outside of top-level object names. I think this is where the overhead of TDD really becomes an issue--and where tools and techniques are most needed.
I suspect that we need tools that support the option of evaluating our entire schema and generating existence/creation tests for all the details--so we can generate the tests as we go--and that the tool to do this will heavily if not exclusively use the INFORMATION_SCHEMA views which are part of the ANSI SQL standard, and which Joe Celko notes that this is SQL describing itself.
As the tool above is not available at the moment as open-source for SQL Server to my knowledge, I use RedGate's SQL Toolbelt tools to generate create scripts.
3. The discussion posts have mentioned that tests come in more than one category. After reading these brief comments, I still think most people will leave with the categories unclear--functional, performance, unit, existence, etc. So, perhaps someone would like to clear it up along with any needed points on what kinds of techniques lend to the various categories.
Bill Nicolich: www.SQLFave.com
Daily tweet of what's new and interesting: AppendNow