TDD is one of those subjects I'm torn on. On the one hand it is unequiocally a good idea, of COURSE you want to test everything!
On the other hand, as my company's sole IT person it's nearly impossible--even when you write the code in small testable chunks.
On the VB.NET side the front end has an array of automated tests to make sure all the t's are crossed and i's dotted simply because I don't have any one to QA the program! So automated repeatable tests are pretty much the only testing there can be, short of end-user production complaints. (and oh, how Einstein-like users are in discovering new and interesting ways to trash a system...)
But it mainly tests to make sure all the properties of objects are properly set. Unit tests and integration tests and all the rest are possible because it's all generic, all OOP. You're testing that blanks have been filled out more than you are new code.
In a way that's desirable, of course. The less code you need to write the less that needs testing.
And then there's the T/SQL side. (facepalm)
To the good, each function or SP is pretty much single-purpose by necessity. In theory that makes everything easier to test.
But to the bad, T/SQL is PATHOLOGICALLY MURDEROUS to the concept of generic code. Everything needs to be custom written in every SP or performance just falls off a cliff. Generic code is testable code, folks! The less code the less testing needed!
Not to mention T/SQL is aggressively crude. By which I mean it offers almost no reuseability capabilities, unless you want to go the dynamic SQL route, which is unwise from both a performance and security standpoint.
Yes, there are workarounds, but T/SQL takes an almost gleeful delight in making the programmer do drudge work, copy and paste becomes *desirable* as a technique. (shudder).
In fact, writing programs to create SPs is almost a necessity for any database of any scale. And lets not even mention T/SQL's sheer verbosity. I'm no fan of C-syntax brevity-to-the-point-of-obscurity, but my God! T/SQL is way too close to the COBOL end of the scale for my taste.
In short, TDD in a database is kind of difficult, and the database fights you. It wants a static definition of code structure (constraints, etc) rather than a dynamic one.
Also, TDD works, but as the the editorial points out it requires knowing what you want in the first place. Something users aren't really a fan of... 🙂
Thus my conflicted feelings on the subject.