Toad World® Forums

Adding additional info into exported file


#1

The scenario is like this:

  • In dev box we create test definitions
  • We export test definitions from dev as .qut files
  • We check in test definitions using source versioning control software (MKS)
  • We import test definitions in QA box executing .qut

We don’t know what test definition version was applied on QA.

The source versioning control software (MKS) finds for $Header$ tag and replaces it with the version if $Header$ tag exist in the source code.

I added $Header$ from Tools -> Formating Options -> Header and then Tag line enable but is not working. Is there any other way to accomplish it?

Thanks in advance.


#2

Currently there is no way to do this without editing the header of the .qut file after it is created.

But we should be able to add this feature in 1.9, under development now.

I need, however, to make sure I understand fully the requirements. Please tell me if I write below is accurate or needs to be changed in any way as specifications for the ER.

You put a specific string, like “$Header$” somewhere (anywhere?) in the file you are checking in. On check in, the VC system replaces that tag with a specific version string. THen when you check out you get that additional information in your file.

Is that right?

If so, here’s what I think we can do:

  • Add a column to the test definition header table “import_version” that would be populated with this version information after import is completed.

  • Provide a preference where you specify the fixed string that needs to be put into the export file.

  • On export, we put that string into the export header (both .qut and .xml).

Let me know if this makes sense.

Thanks, SF


#3

You put a specific string, like “$Header$” somewhere (anywhere?) in the file you are checking in.

Yes, we do something like this:
CREATE OR REPLACE package pck_name AS
is
– ‘$Header$’; --> AS A COMMENT

end;

or doing it in a constant variable

CREATE OR REPLACE package pck_name AS
is
v_version VARCHAR2(512) := ‘$Header$’; --> AS A CONSTANT

end;

I like more using a constant since if the package is later wrapped still I can see constants (but that is different issue)

Once we check in the VC system replaces it with:

– $Header: package_name.pke 1.3 2009/06/16 09:54:30PDT Programers Name Exp
or
v_version VARCHAR2(512) := ‘$Header: package_name.pke 1.3 2009/06/16 09:54:30PDT Programers Name Exp’;

So then we recompile the package again (now includes the full info in $Header$) so anyone that open the package in the DB can see what version is it.

So what you said has sense on my case if we will be able to see the string as a comment or constant in the Oracle user_source dictionary table.

Hope this help to clarify the issue.
Thanks again Steven!


#4

OK, then here is the plan:

We will add a column named “import_version” to the qu_harness table (top level of test definition hierarchy).

By default it will be set to null.

When you export, the value for this column in the export file will be set <vc_pref_string> where vc_pref_string is the version control preference string, which you will set in the Preferences window.

On check in, your VC system should automatically find this string and replace it with the version.

On check out and import, the string will now be set to the version info, and this will be inserted into the import_version column. You can then query the contents of this table to verify the version. It will also be visible in Test Editor.

Sound good?

One question: this means that on each import, the previous version info will be wiped out. Do you see any reason to keep a “history” of import versions?

Regards, SF


#5

CREATE OR REPLACE PACKAGE MY_SCHEMA.“Q##MY_PACKAGE” AUTHID DEFINER
/*
| Automated Test Package for MY_PACKAGE
| Generated by Quest Code Tester for Oracle.
| Visit the user community at http://unittest.inside.quest.com/index.jspa
| Generated on 2009-09-03T15:55:52
|
| $Header: my_package.pck 1.3 2009/09/03 09:54:30PDT John smith (jsmith) Exp $
|
*/
IS

I appreciate your prompt responses.
Thanks,
Ricardo.

One question: this means that on each import, the previous version info will be wiped out. Do you see any reason to keep a “history” of import versions?

There is no reason to keep a “history” of imported versions in Quest Code Tester. The history is maintained by the revision control system. The goal here is to know what version/revision was imported into DB.

IN the meantime I tried using qu_harness description attribute:
I updated the export file .qut adding the $Header$ as input:


QU_HARNESS_xp.import (universal_id_in => ‘{72B27EC3-2B13-720A-E044-080020ADEF38}’,
harness_owner_in => ‘MY_SCHEMA’,
name_in => ‘Q##MY_PACKAGE’,
description_in => ‘$Header$’,

Then I check it in the code and then the export file was replaced to something like this:

QU_HARNESS_xp.import (universal_id_in => ‘{72B27EC3-2B13-720A-E044-080020ADEF38}’,
harness_owner_in => ‘MY_SCHEMA’,
name_in => ‘Q##MY_PACKAGE’,
description_in => ‘$Header: my_package.pck 1.3 2009/09/03 09:54:30PDT John smith (jsmith) Exp $’,

Then I imported and queried the qu_harness table and I can see the new value in description column but it seems that description column is not being used when Q##MY_PACKAGE package is being created on the fly.

So as results of using import_version should be like this:


#6

You’ve come up with a fine workaround - putting $Header$ in the description field.

Then you noticed that we do not put the descriptions into the generated test code.

That is true. I can change it (slightly complicated - what if the description contains “*/” terminating the comment?) to include those descriptions. I suppose that could be helpful.

This will be in 1.9.

But I still think that it will make sense to have a special column just for that purpose.’

Which ALSO must be put into the test code!


#7

stevenfeuerstein wrote:

But I still think that it will make sense to have a special column just for that purpose.’

Which ALSO must be put into the test code!

Yes, I agree. Thanks!!!


#8

Steven,
Probably you could also send as output parameter the import_version in qu_test.run_test_for.


#9

I will add this to the ER.