In the native database environment Unit Tests can be executed in three different ways:

  1. Running individual Unit Test stored procedure; 
  2. Running all Unit Tests for a given Test Suite; 
  3. Running all Unit Tests in the database;

In addition we have provided DB Test Driven Tool Kit that turns DB Test Driven framework into additional and essential part of any continues integration process.  

Running individual Unit Test

Individual Unit Tests can be executed the same way you would execute any other stored procedure. Successful outcome will not produce any results nor will it raise any exceptions. Test failures and errors will be reported in the same way as any other database errors. 

Although it is permissible to execute individual unit tests, it is less convenient way to utilize framework functionality. There are a few cases, however, when executing individual unit test becomes beneficial:

  • when troubleshooting an issue; 
  • to execute ignored test;  

Note: running individual unit test will not update test statistics information in the DBTD_TBL_TESTRESULT table, but it will provide some of the log data in the DBTD_TBL_LOG table.

 

Running all Unit Tests for a given Test Suite

Unit Tests can be organized in to Test Suits and then can be executed all together as a group.

To run all tests in given Test Suite use DBTD_RUNTESTSUITE stored procedure.

There a many advantages to use Test Suites:

  • Failed individual Unit Tests will not prevent other tests from running;
  • Environment can be prepared with setup procedure UT_SuiteName_Setup at the beginning of each test execution (pic. 1) or at the beginning of the suite execution (pic. 2);
  • Environment can be restored to predefined state with teardown procedure UT_SuiteName_Teardown at the end of each test execution (pic. 1) or after all unit test are executed in the given suite (pic. 2);
  • Statistic information is generated and stored in the DBTD_TBL_TESTRESULT table while Test Suite is running. This information includes: o timestamp when test is started, o timestamp when test have finished, o the number of times test run, o execution status and other values;
  • Detailed log records are available in the DBTD_TBL_LOG table;
  • User can specify what unit test should be ignored when running Test Suite. Check DBTD_IGNORE framework procedure for more information;
  • By executing individual test suites one after another user can manage process flow and enforce execution order. This approach is very beneficial but on down side it will require tighter collaboration between developers and have a risk of skipping some of the new suites that developers created, but have not configured yet.
  • Note: The default framework behavior is to execute setup and teardown procedures for each individual unit test, to change this behavior use DBTD_RUN_ONCE hint procedure  

Run DBTD Test Suite A

Pic. 1

Run DBTD Test Suite B

Pic. 2

Note: framework does not guaranty that unit test in the suite will be executed in a particular order;

 

Running all Unit Tests in the database

To run all unit tests in a database use DBTD_RUNTESTS stored procedure, it will execute all unit test suites in the database by individually running each Unit Test Suite.

In addition to all benefits that come with a suite this method provides a few more important aids:

  • Executing all the suites in the database will make sure that all available and not ignored Unit Tests in a given database will be executed
  • Testing environment can be prepared with Global Setup procedure UT_Setup at the beginning of the process (pic. 3);
  • Testing environment can be restored to predefined state with Global Teardown procedure UT_Teardown at the end of the process (pic. 3);

Run All DBTD Unit Tests

Pic. 3

Note: using this method does not enforce an order in which unit test suites will be executed, neither it enforce specific order in which individual test will run within a suite;

See Also