Hey krispokkuluri,
If I understand what you're asking for, this doesnt sound that complicated, however, the problem is that you're going to need good SQL to be able to pull this off.
What I mean by this is, if you need to verify the storedprocs are doing what is required, then you'll need to be able to turn those stored proc requirements into SQL - thinking about the typical stored procs I see, you'd need to at least be able to put together inner/outer joins, sub-queries and perhaps even use some SQL functions like CAST, CASE & COALESCE to match the requirement.
Initially I think I'd create the JDBC DB connection in the JDCB Connection profile 'Preferences'
In my test case I'd create a copy of the stored proc in a JDBC test step
I'd have a groovy step to write out the results to a Properties step
I'd add a Properties test step
I'd have a JDBC test step containing the SQL I'd put together to match the requirement
I'd have a groovy step to do grab the results of the SQL, write it to the Properties step and then compare the storedproc results against the SQL step's results
So my testcase hierarchy would be something like the following:
JDBC TestStep (storedProc)
Groovy TestStep (grab storedproc, write results to Properties step)
Properties
JDBC TestStep (SQL)
Groovy TestStep (grab SQL, write results to Properties step and compare storedproc results against SQL results)
You wouldn't be able to use the website's front end for a couple of reasons - firstly ReadyAPI! doesnt capture front end content - you'd need something like Selenium to do this - you can use groovy and import declare Selenium, but that's just adding more complication and I think this is gonna be complicated enough for you) - secondly - yes the front end is displaying data sourced from the database - however, you do not know if the data displayed in a specific field in the HTML table on the page is actually sourced from the correct table.attribute in your database. This is one of the reasons when testing front ends, you should actually alter the underlying table's data so that all data displayed on the page is unique - to ensure that page.field1 is being populated by table.field1 correctly - rather than page.field1 being incorrectly populated by table.field2. Hence the reason you should disregard the front end and just focus on the underlying database.
It sounds like you're quite new to ReadyAPI! and if you're not well versed in SQL, I think this is going to be rather a tall order for you. Are you working with anyone who knows ReadyAPI! and has good SQL skills? Even if your SQL is very good doesn't necessarily mean your T-SQL or PL/pgSQL or PL/SQL (T-SQL, PL/pgSQL, PL/SQL are used by SQLServer, PostgreSQL and Oracle to create their storedprocs) is good.
A further complication is how your requirements describing the storedprocs are defined. Will you have a textual description defining the requirement of what the storedprocs are supposed to be doing or are you expected to analyse the storedprocs yourself to determine what they are doing? If the latter, then you'll definitely need to have excellent T-SQL, Pl/pgSQL, PL/SQL, etc.)
Sorry I can't be a bit more encouraging, but I think what you're asking is a tall order unless you're SQL is very, very good along with very good ReadyAPI! skills.
Cheers,
Rich
