I was getting into an argument with some Agile XP people who were making out that they were the first to see the central importance of unit-testing when developing software. OK, I thought, I've been writing functions, views and procedures in TSQL for years, and I've always had that focus. You sit down at the keyboard and you say to yourself, How in the blazes am I going to test this routine I haven't yet written? Once you've worked out how you can test it, Then you write it. Surely the principles of Test Driven Development (TDD) have been around for years?

It is the same with performance profiling. I'd have thought it is always better to design routines in a way that makes it easy to monitor performance issues, than to wade in retrospectively. (I use a debugging log to do this, that is switched in or out as required)

I've worked with many other SQL Developers who have done it a similar way, even to the point of using test harnesses in VB or C++/C#, but there are a whole lot of other ways of writing TSQL, especially now we have the profiler, can read execution plans (with Grant's book there and open at the right page), and all sorts of other tools to make life easier.

I had the idea a while back of writing something about developing SQL Code using very simple test harnesses. I was then gripped with panic, thinking that it was possibly a completely unnecessary skill, now that the information we can get about the dynamic behaviour of SQL routines is so sophisticated, and I'd make a complete idiot of myself describing it. But then, the Agile people got me thinking again....