I'm wondering what others think of the idea of including adding the capability to incorporate user defined assertions. I have a set of stored procedures for which I would like to test the signatures (i.e. input/output parameters, result set count, result set column names and order).
The IMatcher interface does not fit the bill here because it doesn't have access to the DatabaseResults which contain the ResultSetMetaData information I need.
I was thinking that the current map of assertion types could be implemented in a similar way mapping things like "exception-matches" to a class name that implements an interface (IResultsAssertion or something like that).
It might be possible to do what I need with a custom tag handler (something like <resultset-signature>) but I'm not familiar enough with the code yet to understand how feasible that would be.
Thoughts?
For the moment, I'm going to look into adding a new assertion type that matches the result set signatures without considering row counts or values. If this proves fruitful, do I simply contribute back via CVS or is there a regulated process for submitting?
Thanks,
Shane
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just wanted to add a note that I did find a section in the documentation on adding assertion types. I'm fairly new to SQLUnit, so I might be missing something, but I still think there might be value in supporting multiple disjoint assertion types. And, while we're at it, we could avoid the need to recompile the library.
The change that I have in mind would involve promoting the assert attribute to its own tag. The test would look something like this (just off the top of my head):
I'm wondering what others think of the idea of including adding the capability to incorporate user defined assertions. I have a set of stored procedures for which I would like to test the signatures (i.e. input/output parameters, result set count, result set column names and order).
The IMatcher interface does not fit the bill here because it doesn't have access to the DatabaseResults which contain the ResultSetMetaData information I need.
I was thinking that the current map of assertion types could be implemented in a similar way mapping things like "exception-matches" to a class name that implements an interface (IResultsAssertion or something like that).
It might be possible to do what I need with a custom tag handler (something like <resultset-signature>) but I'm not familiar enough with the code yet to understand how feasible that would be.
Thoughts?
For the moment, I'm going to look into adding a new assertion type that matches the result set signatures without considering row counts or values. If this proves fruitful, do I simply contribute back via CVS or is there a regulated process for submitting?
Thanks,
Shane
I just wanted to add a note that I did find a section in the documentation on adding assertion types. I'm fairly new to SQLUnit, so I might be missing something, but I still think there might be value in supporting multiple disjoint assertion types. And, while we're at it, we could avoid the need to recompile the library.
The change that I have in mind would involve promoting the assert attribute to its own tag. The test would look something like this (just off the top of my head):
<assert-definition name="my-custom-assert" class="..."/>
<test name="mytest">
<assert>resultset-types-equal</assert>
<assert>number-resultsets-equal</assert>
<assert>my-custom-assert</assert>
<stmt><sql>....</sql></stmt>
<result>...</result>
</test>
If there is any interest in this type of functionality, I'd be happy to work on an implementation.
Thanks,
Shane
Hi Shane,
This is a good idea - not sure if there is interest in the group or not, but I would suggest you go ahead and do it, and submit a patch for this.
-sujit