|
|
Posted by serge on 11/11/05 06:33
My project is to automate testing of Stored Procedures
of type SELECT (at least for now).
I want to create a table where each stored procedure's
input parameter values are entered and in another table
the expected result value(s) are entered when executed
against a sample database containing manually entered
and verified data.
My current problem is that the stored procedures' input
parameters range from none to 50 parameters (ok now
that I think of it maybe this SP with 50 parameters is an
INSERT SP; regardless let's assume I have SPs that
require 10-20-30+ parameters).
My other problem is each stored procedures' returned
result could fall into any of these four categories:
- 1 row, 1 column
- 1 row, many columns
- many rows, 1 column
- many rows, many columns
So far I thought about 3 ways of storing the data:
1- 1 large table with 50 columns that can hold various
number of input parameter values. Similar type of table for
holding the output result for the four categories above.
2- 1 small table holding one value per row. All kinds of joins
with other tables to indicate which SP and which column the
value belongs to...
3- 1 individual table per stored procedure, this way the number
of columns in the table would match exactly the number of input
parameters.
Obviously the above 3 categories could apply both for the input
and output data.
Now I'm still in research mode and I haven't decided on any choice
yet. And I know each approach has serious consequences; let's just
say they are all with some limitations.
Has anyone dealt with this scenario before? This is the first time I
need a table to hold various types of returned data.
Just to give some numbers: possibly a few thousand SPs and very
likely each SP would have more than one test scenario.
What would you suggest?
Thank you
Navigation:
[Reply to this message]
|