Toad World® Forums

User interface stuff


My company has bought 10 licenses for QCTO. But I have a feeling we will not be using it. Admittedly we are new to the product – but I have quite a bit of JUnit in Eclipse experience, and even I find the user interface baffling. I’m not asking people to “explain” it to me. Rather I thought I should say what I expect to find when I start it up.

Firstly, on start up, I expect it to display to me the tests that have been created in the schema I log in to. It does not; everything is focused on creating tests. That is important, sure, but by no means the most obvious bit. Indeed there is no menu option to do so. All that is displayed is a button to create new tests. I happen to know that all the tests address packages in another schema. I happen to know that in that schema, in pkg_common there are tests. But I cannot find this out unless I run a report or else try to create a new test for that package. And when I do the latter, it “helpfully” invites me to erase all the existing tests (which is horrifying, right there).

How do I suggest it should work?

Firstly, expect the install to be into a separate schema, in which the tests will live. No-one, no-one will want all the clutter in the same schema as the code, so this will be normal. If someone puts it in the same schema, fine, of course.

Secondly, on entry display the tests in the repository. Group them by package,function, etc, indicating the schema they are testing.

Thirdly, enough of the weird window processing. Do something like Eclipse/JUnit or Explorer.

Fourthly, consider how people might want to use this. They will probably want to run the tests against several different schemas. It should be simple to point the tests at schema1 on database 1, schema1 on database 2, etc. I couldn’t see how to do this.

Fifthly – if you’re interested in unit testing, you will want to run it in batch. I couldn’t work out how to do this. Get someone new to u/t to read the docs and comment on the WTF sections, because it doesn’t look nice at the moment.

Sixthly - think about source control for the tests. I presume one would do this on an xml export of the tests, but it is not clear that this is so.

I hope that helps. I really wanted to use this tool. But I just don’t see how I can recommend it. It’s good; just not mature enough.



Thanks for taking the time to provide such detailed feedback. This is very helpful!

I am very sorry to hear you find the interface so baffling. Especially if that makes you think you wouldn’t even use the tool! Believe me, I understand what you are saying about some of the “rough edges” of our UI, but many developers are productively using Code Tester. I bet that after a short “learning curve,” you will be able to do some excellent testing of your PL/SQL code with CT.

Now as to your specific points:

  1. "I expect it to display to me the tests that have been created in theschema I log in to. It does not; everything is focused on creatingtests. " I must admit, I do not understand. When you connect to CT, it will indeed show you all the tests defined for programs in the current schema. You can then change the schema to another or All, to see tests defined for programs in other schemas. I must not be understanding the scenario you are talking about.

  2. "On entry display the tests in the repository. Group them by package,function, etc, indicating the schema they are testing. " We currently simply show a list of programs by name. We are looking at redesigning the dashboard for CT version 2 to follow a more typical schema browser format. I imagine this would address your concern here.

  3. “Weird window processing” Ah, yes. We have definitely had people complaining about this. CT2 should ease some but not all of this. Again, I would like to think that while you might find it weird for a little while, you will quickly move past it and be able to use the windows well enough - but maybe not!

  4. “It should be simple to point the tests at schema1 on database1, schema1 on database 2, etc. I couldn’t see how to do this.” You cannot. The architecture I used when first designing CT makes this a significant challenge. I don’t see this changing for CT2, and I agree that it would be very nice to do this. Instead, you must install CT on each instance, and export/import test definitions. How many different instances/databases do you need to do testing on, Roger?

  5. Run in batch: we offer extensive documentation on running tests via command line. We do not offer batch scheduling in the UI, but you can certainly do what you need to do. Did you see this information in Help? Perhaps you did, but I would like to make sure. And what do you mean by “comment on the WTF sections”?

  6. Version control: it would indeed be very nice to integrate with a VCS. We do not do that. Instead, you export and VC that file. We note this in the section on export/import (I found it by searching for “version control”), but probably need to make it more explicit in the Help.

Roger, you don’t see you can recommend CT; it is “not mature enough.” Is it so immature in your mind, that your developers would be better off continuing to write their own test code?

Regards, SF


Thank you very much for your quick and full reply. This is all most helpful.

A bit of background: I’ve come into a project where the idea of unit testing on the database side is unknown. The project itself is many years old, and the code was never designed to be testable. So in a way we’re at the worst end of the project life-cycle. Automated testing should give us a way out of of the mess … if I can persuade people to do it! This can’t be an uncommon situation. So, ease of use is a real necessity. Unless it is easier for people to create tests than hand-code bits of code, they will continue to do the latter.

Now to the points we were discussing, where your comments were very interesting.

  1. I see then that we made a mistake when we started; but it’s a bit too easy a mistake to make. When we got the software, we got a copy of the database, and the software was installed into SYSTEM (yes, I know ; a separate schema would have been my choice. But it makes no difference for this purpose).

The next thing you do is log in. Naturally you log in with the user under which you installed the software (SYSTEM, in this case). I know the screen that pops up tells you not to (because I have now seen that message); but it is easy to miss and I did. If you do that, you find yourself in this morass. I would suggest that you stick a bit of code in that checks userid and pops up a message, if people do this, telling them “don’t log in as this user - you won’t be able to see the tests”.

When I logged in as the userid owning the packages to be tested, then I got the list of tests that I had expected. That looks much more like it! (I then promptly got “ORA-01031: insufficient privileges” (on what? something in the SYSTEM schema?) when I tried to run the tests I had created from SYSTEM – is there an easy way around this?

(I have got to get this out of SYSTEM; I flinch each time I type it! :slight_smile: )

  1. It’s great to know that the listing of tests is being worked on. Something like you get in Eclipse for JUnit (i.e. the Windows Explorer interface) would be what I would want to see here.

  2. Pointing the tests at different databases: let me explain what I was thinking, in my demented way, as I doubt I will be alone in doing this and it may be of interest. What we have on this site is (a) the live system (b) several system test databases, some on different releases of the software to others © a bunch of development databases, also reflecting different releases or simply different teams working on different subsystems. What we will probably need to do is have a schema in each with the tests for the given release. But there might be merit in having one schema in one test database, with a bunch of db links to the databases of that release, and be able to run the tests against some or all of those databases. Then the developers work on the one test schema, and all those db’s get tested. (There may be other ways to do this, but this seemed natural at this stage). In other words, tie the tests to the code release, not to the physical instances.

The alternative approach is that we install CT in each db, but have a “master” set somewhere, where we develop the things. This of course would also be possible. I must think about this, and I appreciate the suggestion.

  1. Running in batch. Yes, I certainly looked in the help file, but the stuff I saw seemed inscrutable to the newbie. I will look again, but you might want to get someone to read this, who is unfamiliar as I am, and write down all the questions he asks!

  2. Thanks for the note on version control. I suspect that the export was the way, but good to know for certain.

Many thanks again for making this tool available. I frankly feel naked working on an old and creaky system without tests, and if we can make this work, we will. Your reply has been enormously helpful.

All the best,

Roger Pearse


OK, I got round the privileges thing by exporting the tests and importing them into the schema I should have created them in. No problems with that.




– From the dashboard, the “test owner” and the “program tested” names

qu_test.run_test_for ( ‘LIBRA’,‘PKG_COMMON’,l_result);



and you get the two parameters from the names in the dashboard for whatever you want to run.

The stuff in the helpfile about running tests in batch also makes more sense once you can see the tests in the dashboard.


l_result qu_config.maxvarchar2;dbms_output.put_line(’----->’||nvl(l_result,‘null’));WHEN OTHERS THEN dbms_output.put_line(’----->’||sqlerrm);