This section provides reference material about DB Test Driven tables, asserts, framework procedures and other objects 

Many administrative and informational activities are performed by using framework stored procedures.

Framework procedures should not be altered directly by any user.

Assert procedures verify an assumption for a given conditions. If assumption is true, then process will continue forward, if it is false then assert procedure will throws an exception and abort unit test execution at exact place where assertion were called.

Asserts can be divided into following categories:

 

Note: Assert procedures should not be altered.

Hint procedures used to change default framework behavior. They are not intended to be used alone, and when called directly they will perform no functionality and log a message into the log table.

N - Netezza
O - Oracle
S - SQL Server

Hint Procedure N O S Description
DBTD_UNIT_TEST     + When this hint procedure found anywhere in the body of the stored procedure, such stored procedure will be identified by framework as THE Unit Test. Unit Test can belong to only one Test Suite. 
DBTD_NOT_A_UNIT_TEST     + When this hint procedure found anywhere in the body of the stored procedure, such stored procedure will be skipped by framework and will not be considered as a Unit Test. 
DBTD_IGNORE + + + When this hint procedure found anywhere in the body of the unit test code, execution of the test will be ignored by a framework.
DBTD_RUN_ONCE + + + When framework finds DBTD_RUN_ONCE hint procedure call anywhere in the body of Suite Setup or Suite Teardown procedures, such setup or teardown will be executed only once for a suite. Default framework functionality will launch setup and teardown independently for each unit test in the suite.
DBTD_USE_TRANSACTION   + + When framework finds DBTD_USE_TRANSACTION hint procedure call anywhere in the body of the Unit Test procedure, then test runner will wrap this Unit Test into a transaction that will be rolled back after execution, this will return database in to a pre-test state. This hint will force framework to use transaction regardless of the test runner options used during the run.
DBTD_DO_NOT_USE_TRANSACTION   + + When framework finds DBTD_DO_NOT_USE_TRANSACTION hint procedure call anywhere in the body of the Unit Test procedure, test runner will NOT wrap such Unit Test into a transaction, and will NOT rollback any changes after execution, leaving behind any changes in the database. 
Hint Procedures N O S Description

N - Netezza
O - Oracle
S - SQL Server

The information used by DB Test Driven framework and its components is stored in special tables known as framework tables.

Framework tables should not be altered directly by any user. For example, do not modify framework tables with DELETE, UPDATE, or INSERT statements, or user-defined triggers.

Reference of documented columns in framework tables are permissible. However, many of the columns in framework tables are not documented. Applications should not be written to query undocumented columns directly.

The format of the framework tables is dependent upon the internal architecture of DB Test Driven framework and may change from release to release. For that reason, applications that directly access the undocumented functionality may have to be changed before they can run in later version of DB Test Driven framework.

This section provides information on additional framework components specific to a database engines or database appliances required to implement DB Test Driven framework functionality. It also lists internal framework objects not intended to be used directly by unit tests.

Compatibility Pack includes:

  • Older and obsolete object used to minimize impact to your existing code;
  • Asserts procedure synonyms;
  • Add-on framework functional used to simplify migration of the unit tests from one database engine to another;