[font="Arial Black"]"Make it work, make it fast, make it pretty... and it ain't done 'til it's pretty."[/font] --Jeff Moden

I not only test each stored procedure, but I test each query in a stored procedure. I test for happy path, not-so happy path, unhappy path, and places that most people don't know exist never mind that there's a path to those places. At the same time, I'm testing for performance and making the code extremely readable along with some substantial comments for the next poor slob that may have to modify my code.

As a result of all my unit and sub-unit testing, I almost never have code come back for a bug or performance problem.

One of the more difficult things to do when testing like that is to convince the managers that it's worth the wait especially if you're the new guy in the company even though they hired you for your years of experience. But it doesn't take long... there's always someone who's willing to risk it all by not testing at all. Those are the people whose time you keep track of along with your own. Then you tell the manager "Remember that project that was finished a month ago? The code was delivered on time for a very aggressive schedule... Ummmm... when are you folks going to be done debugging all the problems you found after release?" They very quickly learn that another "Modenism" rings true...

[font="Arial Black"]"If you want it real bad, that's the way you'll usually get it."[/font] --Jeff Moden

There's also an inmeasurable side benefit to such testing... it's called "innovation". Sometimes developers will come up with some awesome (sometimes totally new) methods for doing things while they're searching for a "fix" to something they found during their own unit testing.

Let me summarize my thoughts... every minute you spend testing during development will save an equal number of hours in post implementation debugging... maybe more. Developers who don't test their own work should be fired. Managers who don't allow enough time for developers to test their own work should be fired. C* upper level management who don't give managers enough time to allow enough time for developers to test their own work should be fired. The Board of Directors and their customers who don't give C* upper level management enough time to... etc, etc.

When it comes to unit testing, s**t flows uphill. 😉