Testing PLSQL code

Question

Hi guys
I working on project where in Oracle9i database there are 90 table and near about 200 triggers,Procedures and functions.My problem is I have to write test cases for all the triggers,Procedures and functions and give them to the Testerso that they can test it.Can Anybody tell me how to do that
Thanks in Advance
Vikramjit

Answer 1

This is not an Oracle thing, this is a general thing.
Rule 1: don't look at the code!
The testers should be considering whether the delivered application satisfies the requirements. Consequently, you need test cases to test what the developers should have written, not what they actually have written. Depending on how low-level your requirements go, you will need one or more test cases for each requirement.
Let's take an example. The application is an insurance claim system. The user requirement to be tested is "the system must print out cheques".
Okay, so we have a piece of system functionality that takes a claims number and optionally an amount; if the user enters an amount the printed cheque is for that amount, otherwise the cheque is for the full amount of the claim. If the cheque is for a partial amount, the amount due must be reduced according. The printed cheque must not exceed the amount due. The cheque printing routine must be able to handle the maximum allowable claim. Finally, remember to look after the pennies when drawing up your test data.
From that the following test cases suggest themselves.
Test Data
Claim No. 1234 for $850.00:
Claim No. 5678 for $850.00:
Claim No. 8888 for $888.88:
Claim No. 9999 for $99999999999999999999999999999.99:
1) Claim No = 1234, amount=100 => result is printed cheque for $100.00
2) Claim No = 1234, amount=null => result is printed cheque for $750.00
3) Claim No = 1234, amount=null => result is properly handled error, claim already paid
4) Claim No = 1234, amount=100 => result is properly handled error, claim already paid
5) Claim No = 5678, amount=0 => result is properly handled error, invalid amount
6) Claim No = 5678, amount=1000 => result is properly handled error, invalid amount
7) Claim No = 5678, amount=-100 => result is properly handled error, invalid amount
8) Claim No = 5678, amount=null => result is printed cheque for $850.00
9) Claim No = 3456, amount=100 => result is properly handled error, invalid claim no
10) Claim No. 9999, amount=null => result is printed cheque for $99999999999999999999999999999.99
11) Claim No = 8888, amount=444.44 => result is printed cheque for $444.44
12) Claim No = 8888, amount=null => result is printed cheque for $444.44
Notes
You will notice that some of these tests must be performed in a specific order. For instance, if you do test 2) before test 1) the expected results are different. However, it doesn't matter if you run test 10) before test 1). Also you have to be on top of your data: you need to know that there isn't a claim 3456 in order for test 10) to pass.
Once you've got beyond this sort of unit testing you need to think about how this requirement meshes with other requirements: for instance, "Cheques can only be printed by authorised users" and "Cheques can only be printed after a claim has had a pay-out authorised".
And so on. By now you may be thinking "This is like writing a program". If that is what you're thinking give yourself a gold star. Wouldn't it be nice if there was a programming language available that would allow you to write these test scripts and run them automatically? You're in luck. You only have to test the database - stored procedures and triggers - so you can use UTPLSQL. This is an open source test harness written in PL/SQL by saint in human form, Steven Feuerstein. It's fantastic. I advise you to check it out: http://utplsql.sourceforge.net/
Using a test harness like UTPLSQL requires some knowledge of the code, specifically which procedures implement which requirements and the signatures of those public procedures. That's all. Testing triggers is done by inserting/updating/deleting rows into the tables and then querying them. UTPLSQL can help with that too.
Good luck, APC