DB2unit : A Unit Testing Framework for IBM DB2

Welcome to the home page of DB2unit. This Sourceforge project was set up to provide a publicly accessible focal point for development, and to pass on code, documentation, news and assistance to everyone interested in this framework.

Unfortunately I ran out of time to work on this. Thankfully the project has been picked up by "angoca" and moved to Github -

DB2Unit Project on GitHub

I've left the initial project details below for anyone who is interested. I believe they still provide some useful information, at least for historians. Bear in mind that this was before the days of autonomous transactions.

What is DB2unit ?

DB2unit is a unit testing framework for IBM's DB2 database management system. In the first instance it concentrates on the DB2 for Linux, UNIX and Windows (LUW) member of the DB2 family : there is a possibility that in the future it will also be expanded to support DB2 for z/OS and other DB2 family members.

Our first focus is on providing support for unit testing DB2 “application objects” : initially user defined functions and stored procedures.

What Stage is the Project At ?

The project is currently in planning stage. Shortly we hope to publish some initial design documents which will start to lay out the resources we must develop, and thoughts on how we will make these resources as generally useful as possible.

What Licence Do You Intend to Use for Any Software Developed ?

We intend to release all software developed by this software under the GNU General Public License (GPL). For more information about this licence please visit the GPL website.

Design Notes
Here are some notes on what we intend to deliver, some of the challenges we envisage facing and thoughts on getting round these challenges.

The process of carrying out a test falls into the following parts -

We believe the only way to guarantee that the database is left totally untouched is to run setup, execute and teardown as one transaction and issue a "ROLLBACK" as the teardown mechanism.  This gives us the challenge of how to execute the checking : the results can only be checked before teardown takes place and anything written by the main transaction will be rolled back.  

This has led us to the conclusion that the only way to effectively check results is using a separate thread of execution.  Moreover, all SQL executed during the checking process would have to be run "WITH UR", otherwise it will wait on the setup/execute/teardown process to complete.   And since the checking process has to run after the execute phase and before the teardown phase, we will need to produce a control program which calls both of them.   

We had originally hoped that execution of a test suite could be achieved by calling a control stored procedure, something like "CALL DB2TEST('testcase-id')", but because we are going to require two separate transactions we do not believe this will be possible.   Another factor in coming to this conclusion is that we would like to have the possibility of storing all our test cases in a separate database.   If we were to call a stored procedure on this testcase database, we would not be able to then invoke the testing or checking procedures directly.

Thinking about this further, it now makes sense from a "Service Oriented Architecture" design viewpoint to have separate services for each of the processes defined above.   However this means that we will have to develop a "contract" for each service : a standard way of calling the services.    It seems logical to define the test case in an XML format, and to pass this XML document into each of the services, apart from the "obtain test definition" service which will output this XML document having been supplied a testcase identifier.

Here we've made a start on listing what we believe needs to be in the XML document -

Database Name (and other connection information)
Type of object to be tested : stored procedure, scalar function, table function, etc.
Execution command
Post execution test command
Post execution test expected output

One layer of complexity which we believe we will have to address is where a database generates values : identity columns, sequences and "not null with default" clauses for date or time values.  When these are produced we will not be able to define the test results as literals; instead we will need to define that the result will be of a certain data type but with a value we will not be able to determine.

Related Information

Here are some sites with information relevant to developers or users of this software -

IBM DB2 Home Page

DB2 for LUW Information Center

Extreme Programming : A Gentle Introduction.

Contact Information

For more information about this project please contact the project administrator at teamdba@scotdb.com.