So of course you would therefore expect that programmers do lots of unit testing and have a correspondingly high level of confidence in their programs. Ah, if only that were the case! The 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 bottom line is that our code almost universally needs more testing. I can't help with deadline pressures, and my ability to improve your manager's understanding of the need to take more time to test is limited. So how about if I instead offer you a "framework" -- a set of processes and code elements -- that will allow you to test your code more easily?
You might even find that by using my framework (code-named utPLSQL for "Unit Test PL/SQL") testing becomes something you look forward to!
Have you heard of "Extreme Programming"? Scary name, but some really great ideas! Check out www.xprogramming.com and www.extremeprogramming.org for lots of information and background. I also recommend picking up a copy of Extreme Programming Explained by Kent Beck. I will offer a summary here and then most importantly apply the ideas to the world of PL/SQL.
We should also be realistic about what we test. We cannot possibly test everything -- but that's not an excuse to do no testing. Any testing at all is better than none. We ought to, on the other hand, focus our attention on those portions of the code that we think are likely to break. Sure, bugs can appear anywhere, but we do need to prioritize our efforts.
"If code reviews are good, we'll review code all the time (pair programming).
"If testing is good, everybody will test all the time (unit testing), even the customers (functional testing)." [page XV]
I'm not going to explore pair programming (in which no one programs alone. Everyone works in pairs; one person works tactically on the task at hand, the other person thinks strategically about ways to improve the code) in this text. Instead, let's focus on "test all the time".
XP recommends that as you write code, you also build unit tests to test that code. To build applications most efficiently, you should also test that code incrementally. In other words, don't write a single, humongous 5,000 line procedure implementing some complex business rule and then try to test that big blob all at once. Create smaller, modular programs that can be tested individually and then combined to implement the business rule.
So: you sit in front of your computer ready to implement a new program. First, write the unit test: what is this program supposed to do? How will I know when it is working properly? Notice that as you build the tests, you are designing the interface and functionality of the program (which is by no means always well-understood before a person starts coding). Once the tests are constructed, write the program (a little program). Then run the tests, fix the code, and get it working. Great! Time to move on to the next program.
Almost any program you write will have numerous scenarios that need to be tested before you can be confident that the code works as desired. You can throw together one or five or ten individual scripts to run those tests, but how easy will it be to run those tests, again and again? If it is not really, really easy (including setting up and cleaning up data), you just won't do it, right?
It is also important to isolate your tests. The failure of one test should not cause one hundred other tests to fail. You lose faith in the results of your tests.
XP recommends the use of a testing framework and supporting code so that you can execute a single unit test or an entire test suite with a single program or even a click on a GUI screen. The tests that you have written run automatically and provide clear indicators of success or failure.
In the utPLSQL framework, a successful run of a test will display the following message:
<package> - SUCCESS
PLVstr - SUCCESS
PLVdate - SUCCESS
whereas a failure will give me a very different result:
Between spaces; expected "is not", got "is not"
Test negative start; expected "a s", got "a str"
Between spaces; expected "not muc|h", got "not much"
Not inclusive; expected "h of a st", got "h of a str"
The utPLSQL software has been designed to offer a robust API so that GUI developers can build front-ends that truly offer Red Light, Green Light visual notification.
Once you have done all that, analyze your code and determine what it is that needs to be fixed. Before you re-run your test, walk through the code and verify to yourself that from a purely logical standpoint it should fix the problem.
Now run your test. You will hopefully (and are much more likely to) get a green light.
The result? Your code has been repaired, you can verify the fix, you have expanded your scenarios for future testing, and you can make sure that the bug never comes back.
Return to: The utPLSQL Project
Copyright © 2009 O'Reilly Media, Inc.