---- sent by Andrey Grigoriev via private mail -----
Hello!
Let me introduce myself. My name is Andrei and I work for 3Com. We use SQLUnit to test our Oracle PL/SQL code for a while. SQLUnit is cool stuff. You have done very good job on it. In addition to that I would like to suggest new feature. SQLUnit runs setup once per file and then all test calls use that data. I have found that it would be very useful to have
capability to prepare data per each test call in addition to setup. I made it locally on my machine by introducing "prepare" node within "test" node.
For that I have created PrepareHandler and made modifications to TestHandler and DTD file.
If you are interested in adding that feature to SQLUnit I will send you a patch. Because it is not a big fix, but rather new feature, I believe that it is worth to discuss it first and then made changes.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was just thinking some more about this, in light of Damon's comment about being more interested in per test setup and teardown. Perhaps we should now offer a way of using the variable names populated in previous tests in the prepare tag as well?
As an example, lets say we populated variable ${myId} with 100012, and in the next test we would like to delete this value as it is likely to interfere with the next test, so we would do something like:
<test>
..<prepare>
....<stmt><sql>delete from mytable where myid=${myId}</sql></stmt>
..</prepare>
.. rest of test here
</test>
This may involve parsing the string with a regex parser and doing a replace before actually running it. Parsing is expensive so I dont want to do this unless there is interest. Would there be interest in this?
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weeeell..the grandfather of SQLUnit allowed that :-).
I first came across the idea of regression testing stored procedures at a previous project where I was the database developer writing stored procedures, where someone had set up a combination of java and shell scripts (before I joined, and very brittle :-)) to send procedure calls and get back results in CSV format. I wrote an improved version, for the same input format, in Perl. However, it did not allow for running SQL statements. A single file would hold the tests for a scenario, such as a customer registering for an account, with individual tests being calls to individual stored procedures. Results of a previous call would be passed to the next one or one later in the chain. "Debug" stored procedures (not to be released to upper layer) would do various housekeeping activities.
On the flip side, it was slanted towards Informix, could not handle multi-row or multi-resultset results, and was very, very hard to read and maintain the test specs :-). One reason was, of course, that to insert a new test for a new procedure, you had to know exactly where to put it into the scenario. Of course, thats probably not as big a deal as it sounds, since the stored procedure writer probably knows enough about the business to figure that out.
In any case, just realized last night that this is a moot point, so even if the variables are carried from test to test, you can use the <param> tags in <sql> to put the values, we dont really need regex parsing. Sorry, I guess I am just long-winded this afternoon :-).
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
---- sent by Andrey Grigoriev via private mail -----
Hello!
Let me introduce myself. My name is Andrei and I work for 3Com. We use SQLUnit to test our Oracle PL/SQL code for a while. SQLUnit is cool stuff. You have done very good job on it. In addition to that I would like to suggest new feature. SQLUnit runs setup once per file and then all test calls use that data. I have found that it would be very useful to have
capability to prepare data per each test call in addition to setup. I made it locally on my machine by introducing "prepare" node within "test" node.
For that I have created PrepareHandler and made modifications to TestHandler and DTD file.
If you are interested in adding that feature to SQLUnit I will send you a patch. Because it is not a big fix, but rather new feature, I believe that it is worth to discuss it first and then made changes.
Thanks.
Andrey has sent me the patches which I have applied and put into CVS. This will be available in the 3.0 release.
-sujit
I was just thinking some more about this, in light of Damon's comment about being more interested in per test setup and teardown. Perhaps we should now offer a way of using the variable names populated in previous tests in the prepare tag as well?
As an example, lets say we populated variable ${myId} with 100012, and in the next test we would like to delete this value as it is likely to interfere with the next test, so we would do something like:
<test>
..<prepare>
....<stmt><sql>delete from mytable where myid=${myId}</sql></stmt>
..</prepare>
.. rest of test here
</test>
This may involve parsing the string with a regex parser and doing a replace before actually running it. Parsing is expensive so I dont want to do this unless there is interest. Would there be interest in this?
-sujit
I'm not sure about this. Carrying variables from test to test removes the notion of isolated unit tests.
but I'm pretty new at this so...
I also believe that test cases must be isolated from each other.
Weeeell..the grandfather of SQLUnit allowed that :-).
I first came across the idea of regression testing stored procedures at a previous project where I was the database developer writing stored procedures, where someone had set up a combination of java and shell scripts (before I joined, and very brittle :-)) to send procedure calls and get back results in CSV format. I wrote an improved version, for the same input format, in Perl. However, it did not allow for running SQL statements. A single file would hold the tests for a scenario, such as a customer registering for an account, with individual tests being calls to individual stored procedures. Results of a previous call would be passed to the next one or one later in the chain. "Debug" stored procedures (not to be released to upper layer) would do various housekeeping activities.
On the flip side, it was slanted towards Informix, could not handle multi-row or multi-resultset results, and was very, very hard to read and maintain the test specs :-). One reason was, of course, that to insert a new test for a new procedure, you had to know exactly where to put it into the scenario. Of course, thats probably not as big a deal as it sounds, since the stored procedure writer probably knows enough about the business to figure that out.
In any case, just realized last night that this is a moot point, so even if the variables are carried from test to test, you can use the <param> tags in <sql> to put the values, we dont really need regex parsing. Sorry, I guess I am just long-winded this afternoon :-).
-sujit