Toad World® Forums

Recommendations for team use of Code Tester


#1

Hi all,
I was wondering if there are any recommendations on how to use Code Tester in a development team? I watched Steven’s webcast about Code Tester yesterday and our entire team is really excited about the tool. But I have been thinking about how to best use it if there are several peoples that should be creating and maintaining tests.

My thoughts so far would be to have a separate installation in each developer’s schema and then (when a test is ready) export the test definitions and load them into a “master” test repository where all tests from all developers are executed. Is this good way to use the tool, or do you recommend another approach (perhaps only one server installation for all developers)?

Looking forward to your comments,
Erik


#2

Glad to hear of your interest in Code Tester!

I would think that generally creating a shared repository would be a better way to go. That way others can see the tests you have created, can run those tests, can learn from what you have done. I don’t really see much of an advantage to separate installs of Code Tester for each developer, EXCEPT:

  • You can currently have only one test definition per program, per repository. So if Joe and Sally both need to build tests for units in package X, they will have to “take turns”.

  • There is not yet any ability to MERGE. So if you have separate installs in schema A and B, and each developer writes a test definition for a PART of package B, you cannot currently merge them into one test definition. This is on our ER list, but I am not sure when we will get to it.

Does this help?

Regards, SF


#3

Yes,
that was very helpful. It is good to know these things upfront, to avoid designing a process which ultimately will not work :-).

We’ll go for the common repository model at this time and see how it works - my team is not that many people so we can probably get this to work anyway.

Thanks,
Erik


#4

Steve,

I’ve browsed the forum for details on how to set up multiple users of QCTO and I found this thread, and also one on ‘Cross Schema Suites’, but I’m unable piece together what I need to do.

I have developed a bunch of test definitions in my development schema (DEV). We perform automated nightly builds in a BUILD schema. Now I want the nightly build to include the running of the tests that I created in DEV.

I have QCTO installed with public synonyms. I gather that I should move my tests from DEV into a shared repository (say, UT), but I don’t know exactly what that means or how to do it.

I would like our nightly build to be able to do the following from the BUILD schema:

qu_test.run_suite_by_name(‘ALL’, lResult);

Can you provide a little more detail to how I can do this, or point me in the right direction?

BTW, in my fumbling, I tried to export my suite from DEV and import it into a new repository (UT), but the import didn’t work successfully. I’m a little nervous about losing my work since I can’t seem to import reliably.

Also, I’m using the commercial version (1.5.1)

Many Thanks!


#5

In a private email, Bindu told me:

DEV and BUILD are both schemas (in the same instance). Our integrator wants to have an automated nightly build (for our UI, server, and DB tiers) that fetches everything from source control, builds it, runs all of our regression tests, and creates installation kits if everything is successful.

Since importing QCTO tests requires human interaction, I was trying to find a scripted way to get the tests into BUILD and run them; or have the tests owned by a different schema (UNITTESTS) and run them from BUILD. But since the tests don’t change often, I can just export the latest tests from DEV and import them to BUILD periodically (only when I have added new tests) instead of trying to import them in the automated nightly script.

And I replied as follows:

Importing QCTO tests does NOT require human interaction. We just don’t document this fact. It is a PL/SQL script. You could run it in Toad, in a batch script, etc. My apologies for us not making that clear; we will update our help doc.