Hi,
If I write two tests in the same file and the first one of them fails the second one just re-iterates the output of the first and fails as well! Maybe I am doing something wrong...
[sqlunit] Tearing down test...
[sqlunit] SQLUnit Tests Failed: In file: U:\TestEnv\Framework\test\mrs_sp_web_lim_hdr_get_test.xml, tests: 2, failures: 1, errors = 0
[sqlunit] One or more SQLUnit Tests failed, see the console for details
Thanks,
Omer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ken Kress had found and fixed this, this was due to the exception message not being cleared. I will check if I "un-fixed" this with my changes and update the thread.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-07-23
thanks :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did test the code today with the scenario you mentioned, and my tests go through correctly, ie:
Test 1: designed to fail
Test 2: desgned to pass
It reports the error on the first and success on the second. It does not carry over the error message from the previous test. While I was doing that, I remembered that Dave discovered a bug in the Sybase ASA (which you may be using, going by your message on NCHAR, etc) driver which just hung onto the result in case of failures. To recycle the connection after each test you can set the reconnect-on-failure attribute of the test tag to true. This will rebuild the connection after every failed test.
Can you give this a try and let me know if this solved the problem?
Thanks
Sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got to thinking about this yesterday, in light of other problems you found, and I think I found what may be the cause of this problem. In my SqlHandler, I am closing the resultset(s), but not the statement. I have put in the fix into CVS now.
This does not appear to affect most drivers, but looks like the driver you are using is less idiot-proof (or user-friendly depending on your point of view) than others and probably insists on the results being closed.
The reason I think this may be the problem is that Dave mentioned the bug in the driver when it keeps the connection in an undefined state when it encounters an exception. However, these are not exceptions, but they still appear to hold on to the previous result, perhaps because of some caching in the Connection object, which I am reusing across tests.
The statement.close() call was inadverdently dropped during the refactoring that went on between version 3.7 and 3.8.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
If I write two tests in the same file and the first one of them fails the second one just re-iterates the output of the first and fails as well! Maybe I am doing something wrong...
The tests are:
<test name="Sample test">
<sql>
<stmt>select count(*) from coef</stmt>
</sql>
<result>
<resultset id="1">
<row id="1">
<col id="1" type="INTEGER">16</col>
</row>
</resultset>
</result>
</test>
<test name="Sample test2">
<sql>
<stmt>select count(*) from ccy</stmt>
</sql>
<result>
<resultset id="1">
<row id="1">
<col id="1" type="INTEGER">216</col>
</row>
</resultset>
</result>
</test>
The results are:
[sqlunit] *** Running SQLUnit file: U:\TestEnv\Framework\test\mrs_sp_web_lim_hdr_get_test.xml
[sqlunit] Getting connection(DEFAULT)
[sqlunit] Setting up test...
[sqlunit] Running test[1]: Sample test (78ms)
[sqlunit] No match on variable at [rset,row,col]=([1,1,1]
[sqlunit] *** expected:
[sqlunit] <result>
[sqlunit] <resultset id="1">
[sqlunit] <row id="1">
[sqlunit] <col id="1" type="INTEGER">16</col>
[sqlunit] </row>
[sqlunit] </resultset>
[sqlunit] </result>
[sqlunit] *** but got:
[sqlunit] <result>
[sqlunit] <resultset id="1">
[sqlunit] <row id="1">
[sqlunit] <col id="1" type="INTEGER">160</col>
[sqlunit] </row>
[sqlunit] </resultset>
[sqlunit] </result>
[sqlunit] Running test[2]: Sample test2 (15ms)
[sqlunit] No match on variable at [rset,row,col]=([1,1,1]
[sqlunit] *** expected:
[sqlunit] <result>
[sqlunit] <resultset id="1">
[sqlunit] <row id="1">
[sqlunit] <col id="1" type="INTEGER">16</col>
[sqlunit] </row>
[sqlunit] </resultset>
[sqlunit] </result>
[sqlunit] *** but got:
[sqlunit] <result>
[sqlunit] <resultset id="1">
[sqlunit] <row id="1">
[sqlunit] <col id="1" type="INTEGER">160</col>
[sqlunit] </row>
[sqlunit] </resultset>
[sqlunit] </result>
[sqlunit] Tearing down test...
[sqlunit] SQLUnit Tests Failed: In file: U:\TestEnv\Framework\test\mrs_sp_web_lim_hdr_get_test.xml, tests: 2, failures: 1, errors = 0
[sqlunit] One or more SQLUnit Tests failed, see the console for details
Thanks,
Omer
This keeps popping up again and again :-).
Ken Kress had found and fixed this, this was due to the exception message not being cleared. I will check if I "un-fixed" this with my changes and update the thread.
-sujit
thanks :)
I did test the code today with the scenario you mentioned, and my tests go through correctly, ie:
Test 1: designed to fail
Test 2: desgned to pass
It reports the error on the first and success on the second. It does not carry over the error message from the previous test. While I was doing that, I remembered that Dave discovered a bug in the Sybase ASA (which you may be using, going by your message on NCHAR, etc) driver which just hung onto the result in case of failures. To recycle the connection after each test you can set the reconnect-on-failure attribute of the test tag to true. This will rebuild the connection after every failed test.
Can you give this a try and let me know if this solved the problem?
Thanks
Sujit
Hi Omer,
I got to thinking about this yesterday, in light of other problems you found, and I think I found what may be the cause of this problem. In my SqlHandler, I am closing the resultset(s), but not the statement. I have put in the fix into CVS now.
This does not appear to affect most drivers, but looks like the driver you are using is less idiot-proof (or user-friendly depending on your point of view) than others and probably insists on the results being closed.
The reason I think this may be the problem is that Dave mentioned the bug in the driver when it keeps the connection in an undefined state when it encounters an exception. However, these are not exceptions, but they still appear to hold on to the previous result, perhaps because of some caching in the Connection object, which I am reusing across tests.
The statement.close() call was inadverdently dropped during the refactoring that went on between version 3.7 and 3.8.
-sujit