Stored procedures and Junit

[Database Administrator]

I work with a bunch of web heads who are big into JUnit testing, code
coverage (of those tests) and metrics on all of that. There is an
sourceforge project for this sort of thins for Orribles' PlSQL.

Has anyone done something similar with Informix SPL? Does it make sense
to? Most of what I am doing is top down and modifies table structure -
not clean functions that have inputs and outputs that can be exercised
12 different ways.

cheers
j.

[Database Administrator]

On Nov 13, 9:30*am, jack.park...@verizon.net wrote:
> I work with a bunch of web heads who are big into JUnit testing, code
> coverage (of those tests) and metrics on all of that. *There is an
> sourceforge project for this sort of thins for Orribles' PlSQL.
>
> Has anyone done something similar with Informix SPL? *Does it make sense
> to? *Most of what I am doing is top down and modifies table structure -
> not clean functions that have inputs and outputs that can be exercised
> 12 different ways.
>
> cheers
> j.

JUnit testing is good for app development. It allows you to test for
an expected value at the component level.
Stored Procedures?
Thats a different animal. JUnits live outside of the application.
Essentially you can take a class, instantiate it and then within the
JUnit, perform an unit of work and test for the result.

Stored procedures live in the database.
If you want to do a JUnit of a java class that connects to the
database, you will need a database that contains a known set of
records and also potentially a set of matching mock data. Then for the
JUnit to function, you have to maintain the database and be able to
reset the database back to a known state.

If you have a java stored procedure, you could use a JUnit test by
having the code outside of engine and then test it via a JDBC
connection. Again, you need to have a known database.

If you're suggesting that you want to create a similar system to
JUnits to test queries, but there's little value there. How often do
you change an SPL or the SQL used in a production environment?

The point is that the Java/Groovy/C/C++ code is going to be changed
more often that the database code. In fact, one of the indicators of
when to use a stored procedure is that the code is fairly static and
is required by more than one application. Repeatable Unit Testing
doesn't make sense for the SPL. However you could call an SPL from a
JUnit as part of the JUnit to test the calling java code.

Bottom line, not worth much, but if you really want to, you can call
the SPL from a JUnit to test it.

HTH

-Mike

[Database Administrator]

Ian Michael Gumby wrote:
> On Nov 13, 9:30 am, jack.park...@verizon.net wrote:
>> I work with a bunch of web heads who are big into JUnit testing, code
>> coverage (of those tests) and metrics on all of that. There is an
>> sourceforge project for this sort of thins for Orribles' PlSQL.
>>
>> Has anyone done something similar with Informix SPL? Does it make sense
>> to? Most of what I am doing is top down and modifies table structure -
>> not clean functions that have inputs and outputs that can be exercised
>> 12 different ways.
>>
>> cheers
>> j.
>
> JUnit testing is good for app development.

But G-Unit is better for crunk and hoes. )

--
Cheers,
Obnoxio The Clown

http://obotheclown.blogspot.com