How to (unit-)test data intensive PL/SQL application
Posted
by doom2.wad
on Stack Overflow
See other posts from Stack Overflow
or by doom2.wad
Published on 2010-04-19T14:19:28Z
Indexed on
2010/04/19
14:53 UTC
Read the original article
Hit count: 273
Our team is willing to unit-test a new code written under a running project extending an existing huge Oracle system.
The system is written solely in PL/SQL, consists of thousands of tables, hundreds of stored procedures packages, mostly getting data from tables and/or inserting/updating other data.
Our extension is not an exception. Most functions return data from a quite complex SELECT statementa over many mutually bound tables (with a little added logic before returning them) or make transformation from one complicated data structure to another (complicated in another way).
What is the best approach to unit-test such code?
There are no unit tests for existing code base. To make things worse, only packages, triggers and views are source-controlled, table structures (including "alter table" stuff and necessary data transformations are deployed via channel other than version control). There is no way to change this within our project's scope.
Maintaining testing data set seems to be impossible since there is new code deployed to the production environment on weekly basis, usually without prior notice, often changing data structure (add a column here, remove one there).
I'd be glad for any suggestion or reference to help us. Some team members tend to be tired by figuring out how to even start for our experience with unit-testing does not cover PL/SQL data intensive legacy systems (only those "from-the-book" greenfield Java projects).
© Stack Overflow or respective owner