Home > SQL Developer: Unit Testing > Unit Testing Best Practices
This topic contains some recommendations and suggestions for using unit testing in SQL Developer:
If you have many packages, analyze the system as a whole to group the packages into functional areas, and create a test suite for each functional area. This process of decomposition can be done recursively, where the ideal situation is come up with small groups of testable objects that have a common set of argument values.
With a test suite hierarchy in place, you can create tests for each object and place the tests into the hierarchy.
Tests should be organized into test suites to facilitate the bulk execution of tests.
Suites can be built from other suites and tests, allowing areas of interest to be grouped together, and even a "super suite" can be created that executes all tests.
Test names are limited to 120 bytes, so test names can be up to 120 characters for a single-byte character set (significantly smaller for multibyte character sets).
Tests are automatically created using the canonical name of the test object (that is, package functions and procedures will be qualified by the package name). For example, given standalone functions or procedures named MY_PROCEDURE_NAME and MY_FUNCTION_NAME and a package named MY_PACKAGE_NAME, the test names will be MY_PACKAGE_NAME.MY_PROCEDURE_NAME and MY_PACKAGE_NAME.MY_FUNCTION_NAME.
If you try to create a test with the same name as an existing test (for example, creating a test multiple times on the same object or on an object with the same name in a different schema), then a sequential number is appended to the new test name. This might result, for example, in the following tests:
MY_PACKAGE_NAME.MY_PROCEDURE_NAME MY_PACKAGE_NAME.MY_PROCEDURE_NAME_1 MY_PACKAGE_NAME.MY_PROCEDURE_NAME_2
However, you may want to consider these alternatives:
If you have objects with the same name in different schemas, it is recommended that you prefix (prepend) the test name with either the physical schema name or a logical synonym. For example, in the following full test names, the last part is the same but the names start with different schema names:
USER3.MY_PACKAGE_NAME.MY_PROCEDURE_NAME USER4.MY_PACKAGE_NAME.MY_PROCEDURE_NAME USER5.MY_PACKAGE_NAME.MY_PROCEDURE_NAME
If there is a valid reason to add a test for the same object more than once, then it may be better to give each test a distinct name it rather than use the default "sequence" approach. For example:
MY_PACKAGE_NAME.MY_PROCEDURE_NAME#LATEST MY_PACKAGE_NAME.MY_PROCEDURE_NAME#COMPATIBLE
When a test is created, a child Implementation of the test is also created. Each implementation forms the configuration for the execution of a test. The first implementation is named Test Implementation 1. You can create additional Implementations to exercise the object with different combinations of values and environment.
It is recommended that you use implementation names that reflect the test strategies. For example, instead of using the names Test Implementation 1, Test Implementation 2, and Test Implementation 3, use names like Upper Boundaries, Lower Boundaries, and Default Values.
The library is a repository of commonly used values (but not data values, for which you should use Lookups). If you find you are entering the same values into the unit testing panels (for example, Startup Process), you can place those values in the library and reuse them in multiple places.
You can take this a step further and ensure that all values are stored in the library, whether they are reused or not. This brings more order to the test building process, and means that as the tested logic changes, it is easy to update all tests accordingly.
Lookups store data type value domains organized into categories. For example, a SALES category might have a NUMBER data type with domain values of (-1, 0, 1, 1000, 1000000000).
Categories can be created to group data type values at a fine grain (for example, EMPLOYEE or SET_3) or at the most coarse grain (for example, DEFAULT).
A test implementation can be associated with only one lookup category, so you can choose a category to cover the values for all the implementations of a single test, in which case it is recommended that the lookup name echo the corresponding test name.
You can execute tests and test suites using the SQL Developer graphical and command-line interfaces. It may be more convenient to use the command-line interface to execute suites or a "super suite" (consisting of all tests).
You could create a generator to run against the UT_TEST and UT_SUITE tables found in the repository schema (or public synonyms for a shared repository) to generate the operating system commands necessary to execute tests and suites.
The Unit Test navigator contains a set of predefined reports to display test execution results.
You can also run a report, right-click on a grid and select Save Grid as Report, and then view the report to see how the unit testing tables have been built into queries.