Toad World® Forums

Count after > count before by


#1

wenn i run some test with list-of-value-parameters (based on a query => many iterations), my expected outcome fails.

my testcode inserts 1 row in table TAB for each iteration.

my outcome looks like following:

TAB count after > count before by 1

only in iteration 1 i get the expected result (1 row was inserted)
(“Count of rows in table = 1356, Expected count= 1356”) => test ok

iteration 2 (1 row was inserted)
(“Count of rows in table = 1357, Expected count= 1356”) => test fails

iteration 3 (1 row was inserted)
(“Count of rows in table = 1358, Expected count= 1356”) => test fails

and so on…

how can i define my outcome, so that further iterations shows “test ok”, when 1 row has been inserted.


#2

Hmmm. I was not able to reproduce your problem in our latest release (1.8.3, which is undergoing final testing and will be released in late April). What version are you using?

I have attached a script and export I used to recreate this problem. You could try this yourself with 1.8.3.
Q##QRT#DTC_INSERT.qut (49.7 KB)


#3

Hmmm. I was not able to reproduce your problem in our latest release (1.8.3, which is undergoing final testing and will be released in late April). What version are you using?

I have attached a script and export I used to recreate this problem. You could try this yourself with 1.8.3.
qrt#dtc_insert.sql (740 Bytes)


#4

when i remove the commit from my testcode and set the test case property “rollback before execution test case”, my test result is ok but the count of rows in the table do not increase and also the expected count of rows do not increase.

when i remove the commit from my testcode and uncheck all the check boxes in the transaction management-properties (no commit, rollback before and after execution of the test), my test fails. the count of rows in the table increases after each iteration, the expected count of rows does not increase.

the same result, when i check the commit-after testrun - checkbox.


#5

we are using version 1.8.2.374


#6

Ah, now I get a sense of what might be causing the problem. By default, Code Tester performs a rollback at the start of each test case. So each previous insert is erased.

Of course, if you have a commit in your program, there’s nothing we can do about that.

So you removed the commit and went with the default rollback behavior and as far as I can tell, everything is fine. Why do you need the count of rows in the table to increase? You are running individual tests against your program and with each execution, it inserts one row successfully. What also do you need to verify/test?

SF


#7

i created a simple insert-procedure (without commit) with a testcase (count after is greater than before by 1).
when the test is running with default transaction-handling (rollback beforestarting testcase), i get the expected result. (the expected count ofrows is the same at each iteration, because a rollback has been performed before each iteration, code tester “knows” that the expected count of rows do not increase).

when the test is running without rollback (or with commit in the transaction-handling-properties of code tester) , the test fails.

i assumed, that code tester “knows”, that the expected count of rows has to increase at each iteration, because code tester is managing the transaction-handling by himself (no rollback, therefore i thought that the expected count of rows should increase after each iteration).

when i “expand” the testcase (without rollback for each expanded testcase), the result is as i expected: after each testcase the expected count of rows increases.

i think it will be very difficult to define some “right” outcome on a program which uses it’s own transaction-handling.

thank you very much for your help.


#8

My apologies for the delay in getting back to you on this.

You have found a bug. We are getting the count ONCE before all the individually generated test cases. We should get the count before each generated TC.

I hope to have this fixed in 1.8.3 (release scheduled for May).

Thanks!
SF