If a unit test never fails, it might never have succeeded

Thank God for the inkling of suspicion that made me double-check a successful unit-test run! Among all the "Agile" buzzwords that pass for development methods, Test-Driven Development is one of those few that really have a lot of value.  But implement it carefully!  Test-driven frameworks save time after you have them working, but don't skimp on building that framework. In my case I could try to pawn off an accusation at a co-worker who integrated utPLSQL into our project.  But the fact is, we hadn't really fully deployed it, and we all knew he had hacked it ... well, you get it. So I was adding some things and I thought I would put tests into the framework for it.  I was very pleased with my craftsmanship (watch for posts on Ego-Driven Programming...).  So I fired up the unit test framework and boy, everything went swimmingly. I added some additional test cases, ran them, added some more, ran them... Ah, success!  Or... hmmm... is something wrong here? Yup, it was.  I could have scrambled my test logic in a blender and still had success reports. Always - ALWAYS - include a mechanism for triggering and verifying EXPECTED failures.  Now our test approach would record these as "known bugs not yet fixed."  Every testing system should have this, so you can get the happy message when a known bug disappears. Extending this sort of facility to provide a sort of self-test of the regression framework is easy and more than worth it.