My career in database goes back to the late 1970's when there was no SQL Server. In those days, you did 90% of your data work in loops. You could watch loops and even build in stops to double-check data as it processed. In essence, you "saw" and tested your work as it processed.

Then along comes SQL. A "Black Box". You stick in a query, and you get data back - but you don't see much in-between.

Test? Unit Test? ARE YOU KIDDING??? To this day I think I am still suffering from some of the early mistrust and panic brought on by SQL many years ago. I don't see how anybody can NOT test. How do you trust SQL, let alone trust yourself???

When you consider (as I have seen many times), that you can mistakenly and yet very simply use say, INNER JOIN when you should have used LEFT OUTER JOIN and this will happily return the WRONG data without a hiccup - YOU'D BETTER TEST!!!

My Rule is simple and absolute - TEST, and do so presuming that you HAVE made a mistake. When you're done with that, pass it up to QA and let them test too. Nothing goes into production until at least two sets of eyes have beaten the tar out of it.

Think about it - in those early days, it was simple to blow things up. But at least when you did that, you knew, ooops, I made a mistake. Now you have SQL where you can screw up big time with a simple valid command, missed punctuation, or other very minor glitch - and SQL will merrily hand you back data - completely wrong data. TEST TEST TEST, and when your done, TEST some more.