|
|
Posted by Steve Jorgensen on 11/11/05 09:01
On Thu, 10 Nov 2005 23:33:16 -0500, "serge" <sergea@nospam.ehmail.com> wrote:
>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
>
Clearly, if you're going to use relational db tables to store the data, the
benefits of 1-m relationships outweigh the benefits of n-columns. That said,
when you're a hammer, every problem looks like a nail, and I'm not sure that
database tables are the best medium for storing your tests or results.
Check out fit.c2.com. Notice that there is a .NET implementation of FIT, that
should work very nicely as a platform to create FIT tests for MS SQL Server
stored procedures, though JDBC from Java would probably work fine, too.
Navigation:
[Reply to this message]
|