Toad World® Forums

external customizations and rollback, simple question


#1

Hello,

I just started to evaluate code tester, this seems an easy question to me, but I couldn’t find the answer in the documentation.

Does the rollback you set with qu_result_xp.rollback_before happens before or after the external initialization?

I would expect before, but this is not the case. Is this normal beheavior?

Same question for rollback after and external cleanup.

Thanks,
Jan


#2

Actually, the rollback behavior does not apply to the external customizations at all. It only works within a test definition, once you have started running your individual tests.

You can kind of see this from the fact that you call

qu_result_xp.rollback_before

in a customization section in the test definition. This code is not run until after the external init. is completed.

So my question to you is:

What do you need? What kind of behavior regarding commits, rollbacks and external init/cleanup do you desire?

Thanks, SF


#3

I want to delete all my data, insert test data, run the tests and then rollback to the situation before the tests.

I tried to rollback in the external cleanup, but I got an ‘external cleanup code failed’-message.


#4

I suggest you put all that code INSIDE the test definition, at the top level of the hierarchy. That is, do not put it in the bottom of that cust. window (external) but above. This way, the data is placed into the tables just before the tests are run, and rollbacks occur by default.

Well, note that rollbacks occur between each test case by default, so if you do set up at the very top level, that setup data could be rolled back too early. So you may want to put your setup logic in programs, which you can do at the top level, then call those programs in each test case initialization.

External init. is really designed for creating database objects, not putting data into existing objects.

Does this help?

SF


#5

Now the data rolls back like it should, but my tests don’t give the desired result.

I have a function where I delete records based on a parameter. I have the ‘quick build’ test ‘delete a row unsuccesfully’.

I enter a value which doesn’t occur in the dataset so the test should pass.

Before I run the test I add to records to the test

The test ‘count of rows’ succeeds, the the ‘table has not changed’ fails

It says there are 2 more rows.

But what is strange is that when I insert a row unsuccessfully, all test pass.

Thanks for your help,
Jan

Message was edited by: jan_leers


#6

Jan,

I think the time has come to actually look at what you have created? Can you create and send to me (steven.feuerstein@quest.com) a support bundle that includes specifically the program you are testing?

SF


#7

Steven,

The support bundle has been send to you. Thanks very much for your time.

Jan


#8

Jan,

Here is the problem:

You have two inserts in your initialization section, but they are not committed.

Then later on in your tests, you use the local copy logic we generate for you to make a copy of your table for comparison purposes.

The code that does this is an autonomous transaction, meaning that the implicit commit of the DDL statement will not force a commit in the rest of the test definition.

It also means, however, that this copy statement does not “see” the data you inserted in the earlier customization section, since it was not committed.

Bottom line: add a commit; after the two inserts, and you should be ok, though better yet, you should delete the rows first, then insert them, to avoid duplicates.

Hope this helps…SF


#9

That seems to be working, thanks.

But now I still can’t rollback to the the situation before the test. Using an commit before saves the data and the rollback fails.

But when all procedures are autonomous transactions, how come the data is saved eventually?

I took an export of the test code, bun executing it was a bad idea, it won’t run anymore, 'list index out of bounds (0). I do some more testing after I’ve set it up again. (restart seems to do the trick)

Regards, Jan

Message was edited by: jan_leers