Toad World® Forums

Support for Conditional Compilation


#1

Conditional Compilation is a nice solution to make private subprograms of packages public for testing purposes.

Conditional Compilation is not supported for the versions 1.8.3 and 1.8.4 (source: http://unittest.inside.quest.com/entry.jspa?externalID=2001&categoryID=138).

But it seems not to work for version 1.9.0.496 either.

Are there any plans to support Conditional Compilation in Quest Code Tester?


#2

We are using version 1.8.4.457 with conditional compilation and it works as advertised. No problems on our side… What problems are you encountering? “Doesn’t work” is not much of a description


#3

The problem is that I don’t see the ‘conditional’ subprograms in the dropdownlist before the button “Refresh Program List” in Code Tester. Even after pressing this button.

I installed the example of Steven Feuerstein in the database (see the attached file). For the subprograms HUMOR_LEVEL and MATURITY_LEVEL Steven used conditional compiling. These subprograms are enabled because ‘show_private_joke_programs:TRUE’.

In SQL*Plus the subprograms HUMOR_LEVEL and MATURITY_LEVEL are visible (see the listing below). But in Code Tester I can’t select these subprograms in the dropdownlist. CALC_HOW_FUNNY is the only available subprogram.

Why are the subprograms HUMOR_LEVEL and MATURITY_LEVEL not visible in Code Tester?

I uninstalled Code Tester and reinstalled version 1.8.5.450 with the corresponding repository. I doesn’t work is this version. Afterwards I upgraded to version 1.9.0.496. But it doesn’t work in this version either.

SQL*Plus> desc sense_of_humor
PROCEDURE CALC_HOW_FUNNY
Argument Name Type In/Out Default?


JOKE_IN VARCHAR2 IN
FUNNY_RATING_OUT NUMBER OUT
APPROPRIATE_AGE_OUT NUMBER OUT
FUNCTION HUMOR_LEVEL RETURNS NUMBER
Argument Name Type In/Out Default?


JOKE_IN VARCHAR2 IN
FUNCTION MATURITY_LEVEL RETURNS NUMBER
Argument Name Type In/Out Default?


JOKE_IN VARCHAR2 IN

SQL*Plus>
sense_of_humor.sql (1.24 KB)


#4

Sorry, I had not yet replied to the post on the forum, because I wanted to see what Alex would say.

So far as I know, we have a “known issue” regarding conditional compilation and it will not work properly, due to parsing issues. Alex, however, claimed to have no problems doing this.

I will follow up with him specifically. In the meantime, unfortunately, you will not be able to use CC to easily hide/expose private subprograms.

SF


#5

Alright, turned out that I lied a little bit…

After some puzzling we figured how we do what we do.
First we compile the specification with the procedure we want to test (the private ones).
Next open up the Test Builder and “Refresh Program List”. Your procedure should be in the list.
Recompile the specification with the Conditional Compilation Flags in place.
Return to the Test Builder and continue with creating your testcases.

If you have multiple private procedures which you want to create testcases for, create a dummy testcase for each of the private programs before recompiling the specification with the Conditional Compilation Flags in place.

(Thanks Bram for this “Bramdini”)


#6

Hi CodeTester-Team

Is there any bugfix available or is there one planned for a next release?
For me, it’s an important feature to use conditional compilation.
Unfortunately, it’s really not usable with Quest CodeTester (using v1.9.1.505).

Thanks in advance.

Regards
Daniel


#7

Daniel,

We do not currently have a fix for this in place, even for Code
Tester V2. However, we will take another look at what it will take to
get this done.

Regards, SF


#8

Hi Steven

Thanks for your quick reply :slight_smile:

I am now doing a workaround with two compilations.
In the first one, I comment out the conditional compilation stuff,
then I refresh the program list in CodeTester and after that, I put it all in again.

Regards
Daniel


#9

Yes, unfortunately that is what you must do - and I don’t think we will be able to change the need for that workaround in the next release.

SF


#10

Hi Steven

I think there is some kind of missunderstanding here. Even with the CC-Flags in place, the exposed procedures / functions are not shown. Maybe, you can have a look at this sample:

CREATE OR REPLACE PACKAGE ut_test
IS
$IF $$unit_testing
$THEN
PROCEDURE dummy;
$END
END ut_test;
/

CREATE OR REPLACE PACKAGE BODY ut_test
IS
PROCEDURE dummy
IS
BEGIN
DBMS_OUTPUT.put_line (‘test’);
END dummy;
END ut_test;
/

SELECT procedure_name
FROM all_procedures
WHERE object_name = ‘UT_TEST’ AND subprogram_id > 0;
– no results shown, since we haven’t set the ccflags
– CodeTester doesn’t show the procedure, this is fine

ALTER PACKAGE ut_test COMPILE plsql_ccflags = ‘unit_testing:TRUE’ REUSE SETTINGS;
– now the package is recomiled with ccflags enabled, therefore procedure DUMMY is exposed

SELECT procedure_name
FROM all_procedures
WHERE object_name = ‘UT_TEST’ AND subprogram_id > 0;
– here we see the exposed procedure

exec ut_test.dummy;
– we can also execute the procedure
– Again, CodeTester doens’t show the procedure

So the workaround for me is not to set/unset the CC-Flags, but instead to manually comment out all the $IF $ELSE $END parts. Is this really the way it’s meant to be? Don’t you use the dictionary views to do your internal parsing stuff?

Many thanks in advance

Daniel


#11

Hi there!

Any news on implementing conditional compiling?


#12

Hi René

I assume you need this for exposing private subprograms in packages? If so, I’ve got a few tricks to make it work and I’ll write a blog post about it when I get time.

Basically, this is what you can do for a hypothetical package SCOTT.PRIV_PUB, assuming that you have exclusive access to this package (the Program Under Tes)t, eg in your own Oracle 10g/11g Express Edition instance on your desktop:

  1. Insert conditional compilation directives into the package spec and body.

  2. Put a comment around the conditional compilation directives in the package spec, ensuring that the private subprograms are exposed. This way, they won’t disturb the CT parser.

  3. Create the Test Definition.

  4. Create external customizations for the Test Definition in order to expose private subprograms before executing the test and hide them after the test has finished, eg:

– External initialization for all unit tests
execute immediate ‘alter package scott.priv_pub compile plsql_ccflags = ‘‘expose_private:true’’ reuse settings’;
execute immediate ‘alter package scott.priv_pub compile body plsql_ccflags = ‘‘expose_private:true’’ reuse settings’;

– External cleanup for all unit tests
execute immediate ‘alter package scott.priv_pub compile plsql_ccflags = ‘‘expose_private:false’’ reuse settings’;
execute immediate ‘alter package scott.priv_pub compile body plsql_ccflags = ‘‘expose_private:false’’ reuse settings’;

  1. Remove the comments inserted in step 2. You probably need to insert them again when refreshing the program from Test Builder with the purpose of adding a new Unit Test (I suppose CT reparses the package spec at this point).

Hope this helps.

Cheers


Finn Ellebaek Nielsen
Oracle Test Coach
http://oracletesting.com


#13

Hi Steven,
Any updates on when/if QCT will manage to support Conditional Compile?

I belive that introducing QCT at my client must be as seamless as possible to get all developers to embrace it.
And Conditional Compile is a sorely needed functionality for us.

Regards,
Magnus


#14

Magnus,

Sorry, currently Code Tester does not support conditional compilation.

But definitely it’s not something CT can ignore. We will consider this feature for a future release.

Thanks,
Roman