Anyone who develops, supports, or uses PL/SQL at some level also tests the PL/SQL. It may not be a formal testing environment, but there is a time where you will probably ask yourself, “Does this program actually do what it is supposed to?” I think this is something we can all relate to as computer users.
 

This type of testing probably involves clicking a few buttons, then poking around the database or file system after the fact to make sure what you expect to see exists. There of course are other types of testing that generally happens inside the development team responsible for the code in question. You have developers writing the code and doing their testing before sending it to the QA group for verification, and then you have the QA group that has a very defined and rigid set of functionality tests that ensure the application does what it is supposed to do. These defined tests eventually get converted into Regression scripts and then are ran as needed to ensure any work done on the code after it has been released does not break anything that was previously working.
 

Ok, so none of this should be news to you, the Oracle enthusiast who is also working with PL/SQL. What may be news to you is that for the past year now Quest has had a technology that can automate this causal to rigid testing methodology for PL/SQL. What’s even more exciting is that in the past release of Toad, this technology has been directly incorporated into your PL/SQL IDE, i.e. Toad for Oracle.
 

 

Ok, I need to come clean just a bit I suppose. Toad cannot look at your code and automatically compose tests for you on the fly and then just run them and let you know how they went. This would be an awesome technology if it existed, wouldn’t it? So what exactly can Toad do for you here?
 

What if you just described in plain terms what your program should be doing, say in terms of:

If you take the few minutes to do this, we can turn these expectations into a testing program that can ensure your code is doing what is supposed to be doing today, and will continue to do so for its entire life expectancy.
 

One other little disclaimer, this technology is actually a stand-alone technology called Quest Code Tester for Oracle. But, if you buy it with Toad, it’s basically half-price, and then you have the instant integration.
 

So if I were to click the ‘magic button’, after I had made a change to my program I would instantly know that all things are not as expected according to my pre-defined tests.
 

 
In about 5 seconds, Toad was able to report back that 1 of our 4 test cases failed. It also was able to show me the actual versus the expected results.
 

When you click the Code Tester button, Toad will open Quest's "integrated testing environment." This is where you will describe your test cases and maintain the test code.
 

 

In about 2 minutes I was able to define 5 test cases that actually run through about 20 different scenarios using the random test input data management piece included in the product. Now, as long as I don’t add new features or drastically change the behavior of the program, I can rely on this test suite to let me know if something happens to break my program. If someone inherits my program later and needs to enhance it, they simply need to take an extra minute to enhance the test suite as well.
 

Have you ever heard the saying ‘Good developers write good programs, but great developers write programs to write good programs for them?’ That’s the essence of what’s happening under the covers hear. Quest has a great developer who had dedicated the last five years or so of his professional career at making this technology available for PL/SQL professionals everywhere.
 

By taking the inputs and scenarios defined in the test IDE, he can transform that into a PL/SQL test package that automates the outcome checks, the running of the tests, and the evaluation of the results so all you have to worry about is ‘Yes this worked’ or ‘No this did not work and here is why’. When you get the ‘No’ answer, don’t despair, just jump into the debugger and run your scenario manually so you can see which line of code is causing the problem according to your expected set of outcomes.

 

 

Here’s your official Toad World homework assignment: