Toad World® Forums

From Test Schema can't see imported tests for Code Schema


#1

I’m struggling to move to a so-called “shared test schema” config. What am I doing wrong?

The goal is put all QCT test definitions in one schema (call this “T”) and to create tests for program objects in a different schema (call this “C”). T is properly setup with the privileges and synonyms needed to access C objects directly.

We backed into this from an initial trial during which many tests for C were created directly in the C schema. But now I want to migrate these tests to the T schema. Accordingly, I have used the command line import command to login as T and import the existing test XML files. Of course, I carefully set the option to import using the login schema (T), not the original schema ©.

This worked, in the sense that all the test were imported. I can verify by querying the QU_UNIT_TEST and QU_HARNESS tables.

But when I login to the QCT GUI as T, no tests are shown! How can I make them appear?


#2

The only thing I can think of is that the harness_owner and/or program_owner columns in the qu_harness table are not set properly. The harness_owner should be set to “T”, which the program owner should be set to “C”.

Can you confirm that this is the case?

SF


#3

Steven thanks for reply Kerry is out sick today we’ll get back on this when he gets better. I’m not sure what system he was on so I can’t respond to your question. I think the problem has something to do with exporting tests and the exports qualify table names with schema names. Maybe there’s some way to configure that to do otherwise. Thanks - Ron Fancher, Hoovers, Inc.


#4

Steven,

Thanks for your reply. I found that program_owner was incorrectly set to T (should have been code schema=C). I made a mistake in the QCT import command line by setting /po=%, which should have been /to=%.

I fixed this, but it didn’t cure the problem.

First, there’s a defect in QCT /Import: the default is supposed to be /po=, but if this is omitted and /to=%, the actual effect is equivalent to /po=%. But I can work around that by specifying /po= explicitly.

Afterward, the /Import result in qu_harness is square: harness_owner=T and program_owner=C. Nevertheless, when I connect to QCT GUI as T, no test definitions appear.

But when I connect as C, they do! Even though there are no rows in qu_harness where harness_owner=C. Moreover, when I try to run, it fails with “ORA-01031: insufficient privileges”. Moreover, I can find no harness package=Q##% anywhere, neither in T nor in C. What the ever-lovin’?

This looks like a show-stopper for us because it means there is no way to use QCT GUI that is compatible with the CI build. Maybe it would work if T=C, but that is not acceptable. That would require the schema-under-test to assume privileges during test (needed for input setup) that it will not have during actual operation, creating a big risk of defects slipping through undetected.


#5

Another problem related to this situation…

Given the current post-import state described previously, the /Delete command line doesn’t work. I expected the following command line to delete everything I previously imported (everything owned by T).

QuestCodeTesterOracle /u=T /DBPrompt=NEVER /Delete /T=* /Close

But it apparently deleted nothing at all. That’s another show-stopper, because it means the the CI build can’t clean up and start tests from a known empty state.

Note that I can use the QCT GUI, logging in as C (??!) to view, select, and delete these tests. This seems to be effective, but it doesn’t help us.


#6

More details about this situation…

I tried to work-around the problem by hacking the Q##*.xml files. Recall that these exported test definitions were prematurely created in the code schema=C. I’m trying to put them into test schema=T where they belong. So I edited an *.xml file, replacing all references to C with T (except for the crucial <PROGRAM_OWNER> setting, which I left set to C). Then, I logged into QCT GUI as T and imported the edited *.xml.

The result? Same. The test was imported and the qu_harness row is correct. But the test does not appear in the GUI. Until I connect as C, at which point it fails to run with ORA-01031.


#7

Can you execute programs owned by C from T through explicitly granted privileges?

Please make sure you can do this OUTSIDE of Code Tester.

I don’t know what else might be causing this problem. You definitely should be able to run those tests in T for programs in C. You just need all the right privileges defined.

Sf


#8

Yes, using sqlplus, can login as T and exec C procedures. All privileges and synonyms to do this are in place.

I’m guessing the ORA-01031 failure is related to the absence of any Q## package following /Import.

QCT seems to be able to submit an email report for this failure. Would it help for me to do this?


#9

Import does not generate a test package automatically. It would happen when you try to run the test, but you cannot see it. Sigh…when you say " can login as T and exec C procedures", are you doing this from within a stored proc as in:

create procedure test_call_from_t
is
begin
proc_in_c;
end;
/

begin
test_call_from_t;
end;
/

This will verify that you have directly granted privileges. A direct call from SQL Plus, as in:

begin
proc_in_c;
end;

will use role-based privileges.

Would it also be possible to install the 2.0 beta and see if you have the same problem with this new version?

SF


#10

Yes, I can execute as in your test_call_from_t example.

Yes, I’m willing to try 2.0. I just downloaded the beta version, and I’ll give it a try.


#11

I’m now trying this using Beta 2.0, and I have new results, which I will post on the Beta forum.


#12

Another detail about this failure on 1.9.505: the problem lies strictly with the GUI. I’ve discovered that when I operate from the command line, things seem to work as expected.

In other words, I can delete all TDs from the sqlplus command line, using PL/SQL. Then I can import all test *.XML files from the QCTO.exe command line (with test owner and program owner schemas set properly. And then I can run all tests from the sqlplus command line, using PL/SQL, and get accurate results. Sweet!

But then the GUI is unusable. As mentioned before, when logging in as T, no tests are visible, and when logging as C, tests are visible but can’t be executed (ORA-01031).

Which is a show-stopper. I can’t use export/import to migrate TDs from schema=C to schema=T, and resume using the GUI to create new TDs.


#13

I now realize that it’s all been a mistake. The tests I thought were invisible in the GUI really aren’t. I just didn’t know how to see them. But I learned how from customer support.

When I connect as T, I don’t see the tests for program objects in schema=C. I totally expected that all tests owned by T would be shown, regardless of program owner. It never occurred to me that it would work any other way.

Also, I had no idea there was a way to change this. I had no idea that little control labeled “T” was a drop-down list – it’s the same gray color as the toolbar. I had no idea what this was for – it has no label that explains what it means. I had no idea this control meant “this is the program object schema you are looking at now – only tests for objects in that schema will be shown”. But sure enough, when I use it to select “C”, all of the invisible tests appear.

Even though the 2.0 GUI is different in a way that makes this confusion less likely, I still see a basic usability problem with QCT. It is cumbersome for those who work like I do: test defs in a schema different from the program objects under test. (BTW, this is how everyone ought to work, because putting tests and programs in the same schema is very risky from a testing point-of-view.) For me, everything I do in QCT centers on the test owner schema=T. This how I always connect. I need to easily access everything that belongs to T.