Database test-driven (DBTD) - is the unit testing framework for database test-driven development (DB-TDD), it utilizes native SQL features, installs directly in to your databases, have small footprint, integrates with build servers for continuous integration capabilities.  

Framework supports following database environments:

  • SQL Server (2008R2, 2012,2014, and Express Edition)
  • Netezza
  • Oracle

DBTestDriven on GitHubDBTestDriven is available
on GitHub

View Alex Podlesny's profile on LinkedIn

Please visit documentation page for more information.

Please welcome the Code Coverage functionality for SQL Server version of our framework. In this version: 


Unit Test is the stored procedure by which individual units of code or individual requirements can be tested. When creating unit test focus on the smallest testable functionality, chose to create multiple simple tests instead of one complex unit test that that combines different logic. Each unit test should be independent and it should be codded with isolation in mind, one Unit Test should not call another Unit Test directly. If both Unit Tests share common functionality, such functionality should be encapsulated into separate stored procedure to achieve desired flexibility.

Use Assertion Procedures to check business logic expectations.

Use DBTD_FAILURE or DBTD_ERROR procedures to implement custom assertion logic, to report errors or failures and stop the test execution.

Use DBTD_IGNORE procedure anywhere in the Unit Test DDL for the test to be ignored.

When you want to wrap Unit Test Execution in to a transaction to make sure that database restored to it original state after rest execution add DBTD_USE_TRANSACTION hint anywhere in the Unit Test DDL, in the similar way you can also prevent use of transactions by specifying DBTD_DO_NOT_USE_TRANSACTION hint in the Unit Test.


Naming convention

Before Version 4.0

Unit test should start with "UT_" prefix followed by the <suite name> and ending with the <test name> 



Note: There should be only two underscore symbols in the unit test name.

Starting Version 4.0

We have relaxed naming convention rules while supporting legacy pre 4.0 naming convention at the same time.

Now Stored procedure with any name (supported by the database engine identifier) can be used as a Unit Test. To differentiate Unit Test stored procedure you would need to call DBTD_UNIT_TEST hint within that procedure.

Note:  SQL Server regular and delimited stored procedure names must contain from 1 through 128 characters. Oracle procedure names should contain from 1 to 30 characters.


Note: Unit test stored procedure should not have any parameters which do not have a default value. 

See Also

Latest News