Main » Quest Code Tester Success Story

Phil Miesle, Solution Architect, Global Scale Solutions, Inc. writes:

"Code Tester is BRILLIANT! I'm now back writing PL/SQL code as part of my job and am able to give Code Tester a decent spin. Fantastic. I find it to be buggy as heck (which I’m putting down to not doing things in exactly the order that is tested…it is v1.0 software), but still *way* better than the alternative “code by hand” (or utPLSQL which was nominally better than coding by hand). Kudos to you and your team!

"I recently attended the TOAD User Group conference and found a really useful piece of kit. It's called Quest Code Tester for Oracle and honestly - it rocks." - Read Brian's Blog at blogspot.com today!

"If you have any significant amount of PL/SQL code, your day of salvation has arrived..."

- Read Steve Callans's product review at DatabaseJournal today!

Chris Taylor, Senior Developer at Fiserv ISS writes: Before Code Tester, there really was not any product available to help create and run PL/SQL tests. As a result, unit testing of my PL/SQL programs was done at the application layer through the use of JUNIT and NUNIT. While these tests worked, we often had to work through application language specific issues and application logic errors in addition to any PL/SQL problems during our unit tests. This made the process more complicated that it needed to be. I was always looking for a way to test the database logic alone without the added complexity of the application code. With Code Tester we can now isolate the database tests. Code Tester is also revolutionary in the way it generates test code for you. With other unit test platforms I have used in the past you had to write all of the code to for your test assertions. Code Tester takes testing to the next level by generating the code for your assertions for you. This has the potential to greatly accelerate the creation and usage of the unit tests. Code Tester generates a lot of complex logic that would have taken significantly more time for me to develop in order to test my PL/SQL packages. I will continue to integrate PL/SQL unit tests using Code Tester into my development process here at Fiserv ISS. I really do think that it will really help me to deliver better database code to the development teams that I work with. I will also be proposing that we integrate the use of Code Tester with all development done by our database team. Another area that I see Code Tester helping with is deployments through our environments. If I have a suite of tests that can be run after a deployment has been completed it could immediately provide me with feedback about the success or failure of the deployment. This validation must currently be done manually and that can lead to oversights.

Scott Schwab from St. Louis writes:

In a push to improve quality and the accuracy of schedule tracking, our Java programmers are expected to use JUnit and provide unit-test with each of their packages. Our PL/SQL developers were asked to do the same, but were left to find their own tools. This search boiled down to three choices: utPLSQL, build their own, or just not do it. The utPLSQL environment worked for the old school, "SQLPLUS is the only tool I'll ever need," type of developers, but it did not catch on with IDE users. Home built systems worked for some, but again the IDE users never found them useful enough to fully test their code, and so "not do it" seemed to win out. As a result, the Java developers are showing improved quality while the PL/SQL developers are not.

This year a new option is available as Code Tester has become available. Code Tester gives the PL/SQL programmers tools very similar to JUnit. The PL/SQL programmers can now bounce between their IDE and Code Tester, adding test, running test, and quickly identifying failures. The success, failure, and cause are just mouse clicks away, not buried in a log file or table.

Personally, I have found that I test more, as I worry about writing the test code less. I create the first test for the package, figuring out what setup is needed and define one test condition. I quickly run this test, get it working, and then copy it multiple times; tweaking it each time to handle the various outputs I should be testing. The cut & paste at a unit test level, which just creates another entry in my test tree browser, allows me to concentrate on what I should be testing, and not worrying if I cut and pasted some code block correctly inside of a long unit test package body.

Code Tester is improving my code, by allowing me to test more, and thereby finding more subtle bugs. Increased testing gives me greater confidence that a package is complete and does what is expected. I can then mark it complete on the schedule, and not worry about having to revisit it to fix bugs, using that time which is never listed on the schedule.