Has you know, I was recently on a PLSQL package to produce a 60 colums report. And it is still buggy. Two lessons for me:
1. Never believe that a code work because you are told so.
2. Begin the job by creating an automated test (...suite).
Not so long ago, I though the idea of Test Driven Development was kinda weird. Why starting by writing tests ? Where is the value ???
Step by step I gave it a chance. It's the only reasonable way to do refactoring. By refactoring, I mean changing large blocks of code, not renaiming functions or deleting unuseful comments.
Now I've figured out that it is the only way to perform as stressfree as possible firefighting (that we all eventually do, don't we ?).
Try to manually check results of a 60 columns sql report 30' before delivery to validate some bug fix. No, don't even try: you can't.
Now I'll let the machine do it for me. EVER. Spending 2 hours to write an automated test suite is not a waste of time, after all.
For Kent Beck fan boys oblidged to develop in PLSQL: a unit test framework ALREADY exists : utplsql (I've never used it yet though).
