I was rooting through the PL/SQL fora on OTN recently, and found a couple of interesting posts about testing.
Firstly, I found this one entitled " Is testing really matter at PL/SQL"
The gist of the post is "do I need to bother testing my PL/SQL?" The OP asks the question because he’s finding it hard to write the tests to do it! It’s an interesting approach – maybe once the code is complete you should just install it, pack up and go home.
Some years back, I worked with a client where this was exactly their approach – the code compiles successfully, therefore there is no need to actually go through the hassle of having to test it as well! Needless to say, when they went live, there were a number of issues, since it didn’t perform as they expected, both in terms of what it did and the performance of the code.
Not an ideal solution, by any means! It may be difficult to do (I’m in the middle of running some complex tests at the moment, which take half an hour to set up and at least an hour to execute each one of the 50 tests!), but if you don’t test it, then unless you are a super-programmer, then it’s not going to work!
The second post looked quite a good one – asking about calling procedures using dynamic SQL. However, in the middle of the thread, comes this post , where the poster suggests that because since "procedures are not formed in an object oriented fashion", it makes it difficult to test them, and so really you shouldn’t bother with testing!
Again, a novel approach to software development – it’s not object oriented, and it’s a bit tricky to test, so we don’t really need to do this!
Hopefully, these are the exceptions to the rule – if it ain’t tested, it shouldn’t be going anywhere near production.