Oracle has decided to add Conditional Compilation to Oracle 10g Release 2. As Bryn Llewellyn states in his white paper Conditional Compilation in Oracle Database 10g Release 2:Unusually, but for very compelling reasons, the feature has been madeavailable in patchsets of releases of Oracle Database earlier than theone that introduced the feature. It is available in Oracle 10g Release1 (10.1.0.4.0) and if you have the right support contract, it can evenbe turned on Oracle 9i (9.2.0.6).

The idea behind Conditional Compilation is, in myopinion, two (or more) fold. One way to use this is to use new codepossibilities in existing packages. Packages that need to run ondifferent versions of the database. Another way to use it, might be toadd debug code to your package, which should not be run in a productionenvironment unless there is a problem.

Now, how do you test all this code. For example using Quest CodeTester for Oracle.In CodeTester it is possible to have only one test set per piece ofcode. So, what if you want to test both versions of your code (or evenmore possible versions if you have multiple flags in your code).CodeTester relies on the existing package and it cannot read the‘hidden’ code. So, if a function becomes private, due to a compilerflag being (un)set, then the test package will become invalid. So, fortesting purposes you want all the programs to be visible and you wantall the flags turned on that will be turned off in production.

I would like to add a helper package though, in which I can read all the compiler flags and according to the state of thoseflags execute a test or not. However, there is currently no possibilityto enable/disable tests on this level. There is a setup procedure (andteardown) for every test, but this is a procedure that will be calledbefore the test runs. You also have a possibility to run code before(and after) all the tests are run. What you would want is a ‘beforetest’ and an ‘after test’ piece of code. This way you would be able toenable/disable certain testcases depending on the state of parameters(or package variable values). Maybe this will be possible in a futureversion of the product.

I agree that we need to support conditional compilation in a much more elegant way in Code Tester.

But in the meantime please note that we have external initializationand cleanup for a test definition (see lower section of Customizationtable at test definition level).

So actually even in today’s version of Code Tester, you can executealter session commands and so forth. Then we will recompile the testpackage….so I think you can achieve some of what you need.

But there is another problem, which you reference: you can change the compiled state of your program, but how we do conditionally change the test code that is compiled? We can no longer reference the program that was now excluded; the test must be disabled.

Well…I suppose you can do that, too. Here is the approach I would take:

Create a program that accepts the name of the unit (and overload, if it is overloaded) and (a) either exposes/hides that unit in the package spec of YOUR package.

This same program also then executes an update against the qu_unit_test table setting testing_status = ‘N’ for that row and saves it. (we should provide an API utility to do this, but it isn’t available yet.

Then you can keep everything in synch.

SF

PS - We are looking to add the capability to define multiple test definitions for a single program in 1.7 (by end of year).