I get great satisfaction out of creating new things, and that is one of the reasons I so enjoy writing software. I love to take an interesting idea or challenge, and then come up with a way of using the PL/SQL language to meet that challenge.
I have to admit, though, that I donít really like having to take the time to test my software (nor do I like to write documentation for it). I do it, but I donít really do enough of it. And I have this funny feeling that I am not alone. The overwhelming reality is that developers generally perform an inadequate number of inadequate tests and figure that if the users donít find a bug, there is no bug. Why does this happen? Let me count the ways...
The psychology of success and failure
We are so focused on getting our code to work correctly that we generally shy away from bad newsóor from taking the chance of getting bad news. Better to do some cursory testing, confirm that everything seems to be working OK, and then wait for others to find bugs, if there are any (as if there were any doubt).
Hey, itís Internet time! Time to market determines all. We need everything yesterday, so letís release pre-beta software as production and let our users test/suffer through our applications.
Managementís lack of understanding
IT management is notorious for not really understanding the software development process. If we arenít given the time and authority to write (and I mean ďwriteĒ in the broadest sense, including testing, documentation, refinement, etc.) code properly, we will always end up with buggy junk that no one wants to admit ownership of.
Overhead of setting up and running tests
If itís a big deal to write and run tests, they wonít get done. Weíll decide that we donít have time; after all, there is always something else to work on. One consequence of this is that more and more of the testing is handed over to the QA department, if there is one. That transfer of responsibility is, on the one hand, positive. Professional quality assurance professionals can have a tremendous impact on application quality. Yet developers must take and exercise responsibility for unit testing their own code; otherwise, the testing/QA process is much more frustrating and extended.
The bottom line is that our code almost universally needs more testing. I recently spent a fair amount of time thinking about how to improve my testing procedures. I studied test frameworks developed by other programmers who work primarily with object-oriented languages. An obsessive coder, I then proceeded to construct my own framework for unit testing PL/SQL programs, which I named utPLSQL, an open source project that is being used by developers around the world. It is complemented by Ounit, a graphical interface to utPLSQL. Letís take a look at how these tools can help.
Please check back next week for the continuation of this article.