< Previous Section: Test an Entire Package API | Next Section: Use Non-Default Prefix >

Put Test Code in Same Package

In some cases (usually when your packages are small and the code you need to write to construct your tests is also constrained), you will not want to bother with creating a separate package to test your code. To do this, you will put the setup, teardown and unit test procedures inside the package specification and body. We look at two examples:

Testing a simple string function
Testing the population of a collection

Testing a simple string function

Suppose I have my basic sting package, containing (for now at least) just a single function:

/*file str.pks */
CREATE OR REPLACE PACKAGE str
IS
   FUNCTION betwn (
      string_in IN VARCHAR2,
      start_in IN PLS_INTEGER,
      end_in IN PLS_INTEGER
   )
      RETURN VARCHAR2;
END str;
/

Now it is time to test the function. I really don't want to bother with a separate package; let's keep it together. To do this, I change the specification to:

CREATE OR REPLACE PACKAGE str
IS
   FUNCTION betwn (
      string_in IN VARCHAR2,
      start_in IN PLS_INTEGER,
      end_in IN PLS_INTEGER
   )
      RETURN VARCHAR2;
      
   PROCEDURE ut_setup;
   PROCEDURE ut_teardown;
 
   -- For each program to test...
   PROCEDURE ut_betwn;
      
END str;
/

The package body contains nothing unusual; it is the same test for str.betwn that you can find in the Testing a Scalar Function example. But when I execute my test, I need to tell utPLSQL that my test code is located in the same package:

SQL> exec utconfig.showconfig
=============================================================
utPLSQL Configuration for SCOTT
   Directory: e:\openoracle\utplsql\utinstall\examples
   Autcompile? Y
   Manual test registration? N
   Prefix = ut_
=============================================================

PL/SQL procedure successfully completed.

SQL> exec utPLSQL.test ('str', samepackage_in => TRUE)
.
>    SSSS   U     U   CCC     CCC   EEEEEEE   SSSS     SSSS
>   S    S  U     U  C   C   C   C  E        S    S   S    S
>  S        U     U C     C C     C E       S        S
>   S       U     U C       C       E        S        S
>    SSSS   U     U C       C       EEEE      SSSS     SSSS
>        S  U     U C       C       E             S        S
>         S U     U C     C C     C E              S        S
>   S    S   U   U   C   C   C   C  E        S    S   S    S
>    SSSS     UUU     CCC     CCC   EEEEEEE   SSSS     SSSS
.
 SUCCESS: "str"

Testing the population of a collection

Collections are very useful structures, but they can be difficult to analyze and compare. utPLSQL provides the utAssert.eqColl and utAssert.eqCollAPI programs to help you do this.

For this example, consider the fileIO package: it implements a path feature for the UTL_FILE package. In other words, you request to open a file and your file-opening program will search through each of the directories in the path in sequence until it finds the file or exhausts the list. Here is the specification of this package:

/*file filepath1.pkg */
CREATE OR REPLACE PACKAGE fileIO
IS
   c_delim CHAR(1) := ';';
   
   dirs dirs_tabtype := dirs_tabtype ();
   
   -- Unit test list
   ut_dirs dirs_tabtype := dirs_tabtype ();
   
   PROCEDURE setpath (str IN VARCHAR2, delim IN VARCHAR2 := c_delim);
   FUNCTION path RETURN VARCHAR2;
   FUNCTION pathlist RETURN dirs_tabtype;

   FUNCTION open (file IN VARCHAR2, loc IN VARCHAR2 := NULL) RETURN UTL_FILE.FILE_TYPE;
   
   -- Unit test code in same package
   PROCEDURE ut_setup;
   PROCEDURE ut_teardown;
   PROCEDURE ut_setpath;
END;
/

A few things to notice about this package:

It declares a publicly available collection, fileIO.dirs, in which the path is deposited. Because it is declared in the package specification, I can use the utAssert.eqColl procedure (if the collection was hidden in the package body, I would have to use utAssert.eqCollAPI).
The test code is in the same package: the setup, teardown and test pogram for fileIO.setpath.
I declare a second, publicly available collection, fileIO.ut_dirs, against which I will compare the path that is populated by fileIO.setpath.

Given that, let's take a look at the implementation of the test program:

PROCEDURE ut_setpath
IS
BEGIN
   /* Populate base collection */
   ut_dirs.DELETE;
   
   ut_dirs.EXTEND(2);
   ut_dirs(1) := 'c:\temp';
   ut_dirs(2) := 'e:\demo';
   
   /* Call setpath to do the work */
   setpath ('c:\temp;e:\demo');
   
   utAssert.eqColl (
      'Valid double entry',
      'fileio.dirs',
      'fileio.ut_dirs'
      );
END;

This program consists of three steps:

Populate the test collection with direct assignments. Call the setPath program to populate the actual collection (fileIO.dirs). Call the assertion program to compare the two. Notice that I pass the names of the collections to the assertion program. utAssert uses dynamic SQL to build a PL/SQL block "on the fly" that compares values from the collections.

< Previous Section: Test an Entire Package API | Next Section: Use Non-Default Prefix >