NVH’s Blog

Print
Email Add to Project
Trackbacks
Blog this

Bookmark with del.icio.us

Aw, Gee, Mom, Do I Have to Test My Code?
by Steven Feuerstein
06/01/2000
Introduction
Resources

• Documentation
• Software
• Register

I love to create 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 using the PL/SQL language (since at this point in my life it is the only computer language I know) to meet that challenge.

I have to admit, though, that I don’t really like to have to take the time to test my software (nor do I like to write documentation for it). I do it, but I don’t ever 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, from even wanting to take the chance of getting bad news. Better to do some cursory testing, confirm that it seems to be working OK, and then wait for others to find bugs, if there are any (as if there were any doubt).
Deadline pressures. Hey, it’s Internet time! Time to market determines all. We need everything yesterday, so let’s be just like Microsoft and Netscape: 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 are not given the time and authority to write (in the broadest sense, including testing, documentation, refinement, etc.) our own 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. I don’t have time, there is always something else to work on. One consequence of this point 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 of 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 have recently spent a fair amount of time thinking about how to improve my testing procedures. I have also 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. I call it utPLSQL. I have teamed up with O’Reilly & Associates and PLNet, a brand-new PL/SQL open source repository, to make this framework (set of packages and procedures for using them) available to all PL/SQL developers.

You will find in the remainder of this article a look at the all-too-typical way we test our code. You will find on this site all the information you need to learn how to leverage utPLSQL in your environment.