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 -
- OBTAIN TEST DEFINITION :
gather the information required to run the case from a predefined
configuration database
- SETUP TEST ENVIRONMENT :
establish a connection to the database containing the application
object to be tested and put any required test data in place
- EXECUTE TEST CASE : run the object using a specific
set of input criteria
- CHECK RESULTS : evaluate
the results of the execution, both by observing the return information
produced and by querying the status of the database and make the
outcome available
- TEARDOWN : put the
database back into the state it was in before the test was started
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.