Version – – DBTestUnit released


Version of DBTestUnit has been released and can be downloaded from SourceForge.

This release implements the name change from ‘Database testing framework’ to ‘DBTestUnit’.

So what has changed?

There has been no change in overall functionality.

Basically, a number of components and namespaces have been changed to reflect the new name.

These include:

  • DatabaseTesting.dll renamed to DBTestUnit.dll.
    The test dll is now found in: …\Projects\DBTemplate\libs\DBTestUnit\
  • DatabaseTesting.ExportDBDataAsXML.exe renamed to DBTestUnit.ExportDBDataAsXML.exe.
    The exe is found in: …\DBTemplate\tools\ExportDBDataAsXML\
  • All sample tests have been updated to reference DBTestUnit.dll rather than DatabaseTesting.dll
  • All namespaces have been updated
  • eg

    using DatabaseTesting.UnitTestBaseClass.MSSQL;

    to d

    using DBTestUnit.UnitTestBaseClass.MSSQL;

    How does this effect using the framework?

    If you are a new user – none. Just download and start using.

    If you are using a previous version – there are a number of relatively minor steps that you will need to carry out if you want to start using the new ‘renamed’ version.

    1. Download the latest version – eg

    2. In your database testing solution remove all references to the ‘old’ DatabaseTest.dll.

    3. Add a reference to the new test dll – DBTestUnit.dll – found in ….\Projects\DBTemplate\libs\DBTestUnit\.

    4. Update any existing namespaces to reflect the new name ie do a ‘find and replace’ changing ‘DatabaseTest’ to ‘DBTestUnit’.


    using DatabaseTesting.InfoSchema;
    using DatabaseTesting.UnitTestBaseClass.MSSQL;


    using DBTestUnit.InfoSchema;
    using DBTestUnit.UnitTestBaseClass.MSSQL;

    5. Next you will need to change the test dll config file.

    In the sample project provided – which uses AdventureWorks database as an example – then the change would be applied to following config file:


    The following change would be made to reflect the changes in the internal namespaces of the testing framework.

    <add key="AssemblyName" value="DatabaseTesting"></add>
    <add key="DaoFactoryNamespace" value="DatabaseTesting.InfoSchema.DataAccess.MSSQL"></add>


    <add key="AssemblyName" value="DBTestUnit"></add>
    <add key="DaoFactoryNamespace" value="DBTestUnit.InfoSchema.DataAccess.MSSQL"></add>

    6. The final part is if you use the XML export tool found in:


    For this, it is probably easier to just take a copy of the latest version of this from the download.

    Make sure that you take a back up of your existing config files as you will need to incorporate them into the ‘vanilla’ config files from the new download.

    And that’s it.

    If you have any problems ‘upgrading’ feel free to contact me.


Database testing framework renamed to DBTestUnit


As of Feb 2011 – ‘Database testing framework’ has been renamed to ‘DBTestUnit’.

All existing database testing content has been copied from – – to this site.

Most of this content has been updated to reflect the name change – from ‘Database testing framework’ to DBTestUnit – but apologies in advance where I have missed some.

The database testing framework – DBTestUnit can be downloaded via this new link.

Feature set for MS SQL, MySQL and Oracle


Last modified: 2011-01-06

The following table shows the supported SQL dbms and testing features.

  MS SQL 2K MS SQL 2K5 MS SQL 2K8 MySQL 5.1 Oracle 10g express
Sprocs/functions Limited*
Sproc/function – test method – ParameterIsSameAsColumn ** ** **
Triggers N/A
Synonyms N/A N/A
Test data sets returned √***
Security and permissions √**** Limited √****

* MySQL 5.1 does not implement INFORMATION_SCHEMA.PARAMETERS. Therefore not all of the frameworks testing functionality is available. It was introduced in MySQL 5.5 – so will be included once this version of MySQL is supported by the framework.

** Not implemented yet – will be implemented in a later version.

***Does not support testing data returned from sprocs. Issue with MS Enterprise Library and Oracle sprocs. Hope to fix in a future release.

****SQLObjectPermission introduced in version will be implemented in a later version for Oracle. Will not be supported for MS SQL2K.

Running your first tests


Last modified: 2011-02-28

This blog is the second in a two part series.

It will look at:

  • running the some simple tests against the database
  • using the provided SQL helper scripts to help get the properties for an existing database.

It assumes that you have read the first blog in the series – initial set up and configuration.

Example test to be run

The DBTestUnit download comes with a number of sample test files including:


(Note ‘DIR’ is used as a token for ‘C:\Projects\AdventureWorks\’ – the example project set up in initial set up and configuration).

This allows tests to be run against the SQL server that hosts the database – to ensure it has the expected properties.

An example is shown below:

using System;
using MbUnit.Framework;
using DBTestUnit.UnitTestBaseClass.MSSQL;
using DBTest = DBTestUnit.InfoSchema;

namespace DBTemplate.DatabaseTest.Tests
    public class SQLServer : SQLServerTestBase
        public SQLServer()
            dbInstance = "AdventureWorks";
            sqlServer = new  DBTest.SQLServer(dbInstance);
            expectedServerCollation = "Latin1_General_CI_AS";
            expectedServerVersion = "10.50.1600.1";
            expectedServerProductLevel = "RTM";
            expectedServerEdition = "Developer Edition";

A number of things are worth noting:

  • This is for MS SQL server. The test inherits from SQLServerTestBase part of the DBTestUnit.UnitTestBaseClass.MSSQL namespace. This would need to be changed if testing Oracle or MySQL.
  • The expected values eg expectedServerVersion – will need to be changed appropriately.

This will be used as an example as it is a relatively straight forward set of tests.

How to run the tests
So assuming that everything has been set up and configured correctly how do we run the tests?

1. Open up the VS solution.

If you haven’t already done so open the solution and build/compile the database test project.

The output of this will be a test dll – for example:


2. Open the MBUnit UI

If you need to install either get the latest version from the MBUnit web site or install if from the DBTestUnit download


In the UI go to the menu ‘Assemblies’ – ‘Add assemblies’

Navigate to and attach the db test dll created in step 1.

Run the SQLServer tests.

If the expected properties in the tests are correct then the tests will pass.

3. What do you do if some of the test fail
This will mean that the SQL server that hosts the AdventureWorks – does not have the properties outlined in test code above.

Therefore the sample test code provided needs to be updated with the correct SQL server properties.

(Note this blog is using the scenario where you are starting to carry out database testing for an existing/legacy database.)

The DBTestUnit download provides a number of SQL helper files that will provide information for an existing database.

These can be found in:


4. Using the SQL helper scripts

The script 001_SQLServerSettings.sql is used in this case.

A part of the script is shown below:

PRINT '********************************'
PRINT '********************************'
PRINT 'ProductVersion: ' + convert(varchar,SERVERPROPERTY ('ProductVersion'))
PRINT 'ProductLevel: ' + convert(varchar,SERVERPROPERTY ('ProductLevel'))
PRINT 'Edition: ' + convert(varchar,SERVERPROPERTY ('Edition'))
PRINT 'ServerCollation: ' + convert(varchar,SERVERPROPERTY ('Collation'))

The values returned when this script is run can be placed in the C# test shown above.

It can then be recompiled and the tests run again in MBUnit.

If the values are correct the tests will all pass.

Round up
And that’s it.

The first blog showed how to configure/set up DBTestUnit, this blog has taking this on and shown how to run some initial tests.

Initial set up and configuration of DBTestUnit


Last modified: 2011-06-08

This is the first in a two part series on how to set up the Visual Studio (VS) template – that is included in the DBTestUnit download.

The second will show how to run tests.

If you already have an existing solution/project and want to start using DBTestUnit – a section is included at the end to cover this scenario.

The following short screencast can be used with the notes below to help set up and configure.

(Screencast was created in Aug 2010)

1. Download the latest version of the DBTestUnit

2. Extract files to where you want to place your database testing solution/project.

In the example below it has been extracted to C:\Projects\ :

DBTemplate default directory structure

DBTemplate default directory structure

3. Rename dirs and files with your database name.

As you can see in the image above by default ‘DBTemplate’ is used as a prefix for many dirs and files.

These should be replaced with the name of the database to be tested.

For this I am going to use the MS sample database AdventureWorks as an example.

Therefore change:

C:\Projects\DBTemplate\ to

Rather than renaming these manually, a bat file – C:\Project\DBTemplate\tools\DBTemplateSetUp.bat – is provided that can do this.

The first section of this file is shown below.

SET dirRoot=C:\Projects\
SET dirParent=%dirRoot%DBTemplate\
SET dbProjectName=AdventureWorks

Before running the bat file – copy it to another directory eg C:\Projects\ and set appropriate values for ‘dirRoot’ and ‘dbProjectName’.

After renaming the directory structure should be similar to the following:

AdventureWorks directory structure

AdventureWorks directory structure

4. Change the VS solution file

Open – C:\Project\AdventureWorks\src\AdventureWorks.sln

Replace ‘DBTemplate’ with ‘AdventureWorks’

5. Change the the db test project file

Open – C:\Projects\AdventureWorks\src\AdventureWorksDatabaseTest\

Replace ‘DBTemplate’ with ‘AdventureWorks’

6. Start VS

Open the solution.

The structure should look similar to the following:

AdventureWorks Visual Studio directory structure

AdventureWorks Visual Studio directory structure

A number of sample unit tests and other files are including the in solution. These will all have the text ‘DBTemplate’ in their namespaces.

Therefore, do a solution wide ‘find and replace’ changing ‘DBTemplate’ to ‘AdventureWorks’

7. Set up the config file to connect to the database to test

If you open up any of the sample tests provided you will see that they all have a variable – dbInstance – which by default has the value ‘AdventureWorks’.

This can be seen at the bottom of the sample code provided below:

using System;
using MbUnit.Framework;
using DBTestUnit.InfoSchema;
using DBTestUnit.UnitTestBaseClass.MSSQL;

namespace DBTemplate.DatabaseTest.Tests.Tables.Schema
    public class SalesOrderHeader : TableTestBase
        public SalesOrderHeader()
            dbInstance = "AdventureWorks";

This is used to provide connection settings to the database to be tested and should be set in the following app config file:


Open this config file.

Go to the connectionStrings section.

The following should be included by default.

<!--MS SQL dbInstances-->
<add name="AdventureWorks" connectionString="Data Source=serverName;Initial Catalog=AdventureWorks;Integrated Security=True;Application Name=AdventureWorksUnitTesting" 

The ‘name=”AdventureWorks”‘ should correlate with the value set in the variable ‘dbInstance’ as show in the test code above.

The connectionString properties need to be changed appropriately eg Data Source=serverName

Once the config file has been updated – that’s it all set up – ready to start database testing.

What do I do if I have an existing project?
If you an existing project and just want to start using the DBTestUnit.dll for testing then it is a bit easier to set up.

Download the latest version of the DBTestUnit as per step 1.

In your existing test project reference the latest version of DBTestUnit.dll. You will also need to reference the MS enterprise libraries provided in the download.

Then amend your existing config file appropriately so that tests can connect to the database.

Round up
This blog shown how to set up DBTestUnit – the second will look at running tests.

Prereqs – what you need to use DBTestUnit


Last modified: 2011-02-28

See related blog – What’s included in the download

To start using DBTestUnit – you just need to reference DBTestUnit.dll and then start using it in your database tests.

The purpose of the table below is to outline what is required for other ‘components’ of the DBTestUnit download.

Supported SQL dbms See supported feature set
SQL helper file Predominantly for MS SQL2K5/8 – though there are some for Oracle.
Solution/project template Built using Visual Studio 2K10 express edition. The project solution template should work with other versions of VS.

Unit test samples are in C#.

Unit testing framework MBUnit 2.41

This and other required external libraries are included in the DBTemplate download.

Other unit testing frameworks – eg NUnit – could be used.

Overview of what DBTestUnit does and how it works


Last modified: 2011-01-08

What it does
1. Test that all expected SQL objects are present
eg the number of tables, views, sprocs, functions, triggers, synonyms etc.

2. Test each SQL object has its expected properties
eg tables have correct columns, defaults, check constraints, unique keys, foreign keys etc.
eg sprocs have expected input/output parameters.

3. Test that SQL objects have expected functional behaviour
eg tables, views and sprocs return their expected data.

4. Test the security/permissions on SQL objects
eg test that the correct users have exec permissions on a sproc.

How it works
When I first started unit testing databases a number of years ago I found that I was writing a lot of boiler plate test code.

For example to connect to the database, to query INFORMATION_SCHEMA/system tables to test the schema, to test the data returned by a table/sproc.

What I wanted to do was to:

  • minimise the amount of boiler plate code required.
  • to make the tests as declarative as possible – writing database tests that focused on asserting my expectations/requirements rather than how to carry out the test.
  • use similar testing tools/frameworks to that of general software development.

Therefore I created a C# library – DBTestUnit.dll – that does this.

The dll abstracts away from the developer of knowing how to carry out the test.

So that, for example, a developer can make simple assertions of what they expect eg that a table A has a number of columns.

The dll has the responsibility of knowing how to test these assertions. For example, by running the appropriate query on INFORMATION_SCHEMA.COLUMNS in MS SQL or DBA_TAB_COLUMNS in Oracle.

A number of examples are shown below that give a brief overview of the types of tests that can be written.

Later blogs will give more detailed examples of how DBTestUnit can be used to carry out the functionality outlined in the first section.

Testing the schema of a SQL table
The sample code below shows part of a C# unit test for the AdventureWorks.Sales.SalesOrderHeader table.

using System;
using MbUnit.Framework;
using DBTestUnit.InfoSchema;
using DBTestUnit.UnitTestBaseClass.MSSQL;

namespace DBTemplate.DatabaseTest.Tests.Tables.Schema
    public class SalesOrderHeader : TableTestBase
        public SalesOrderHeader()
            dbInstance = "AdventureWorks";
            schema = "Sales";
            tableName = "SalesOrderHeader";
            table = new Table(dbInstance, schema, tableName);
            expectedColumnCount = 27;
            expectedColumnList = "SalesOrderID,RevisionNumber,OrderDate,DueDate,ShipDate,Status,OnlineOrderFlag,SalesOrderNumber,PurchaseOrderNumber,AccountNumber,CustomerID,ContactID,SalesPersonID,TerritoryID,BillToAddressID,ShipToAddressID,ShipMethodID,CreditCardID,CreditCardApprovalCode,CurrencyRateID,SubTotal,TaxAmt,Freight,TotalDue,Comment,rowguid,ModifiedDate";
            expectedTriggerCount = 1;
            expectedTriggerList = "uSalesOrderHeader";
            expectedPKName = "PK_SalesOrderHeader_SalesOrderID";
            expectedPKColumnCount = 1;
            expectedPKColumnList = "SalesOrderID";
            expectedUniqueIndexCount = 3;
            expectedUniqueIndexList = "AK_SalesOrderHeader_rowguid,AK_SalesOrderHeader_SalesOrderNumber,PK_SalesOrderHeader_SalesOrderID";
            expectedNonUniqueIndexCount = 2;
            expectedNonUniqueIndexList = "IX_SalesOrderHeader_CustomerID,IX_SalesOrderHeader_SalesPersonID";
            expectedClusteredIndexCount = 1;
            expectedClusteredIndexName = "PK_SalesOrderHeader_SalesOrderID";
            expectedNonClusteredIndexCount = 4;
            expectedNonClusteredIndexList = "AK_SalesOrderHeader_rowguid,AK_SalesOrderHeader_SalesOrderNumber,IX_SalesOrderHeader_CustomerID,IX_SalesOrderHeader_SalesPersonID";
            expectedDefaultColumnCount = 9;

In the code above the expected properties of a table are set declaratively in variables.

For example, expectedColumnCount = 27 asserts that the table should have 27 columns.

This combined with the variable expectedColumnList can test that the table has the correct columns.

When the test is run, DBTestUnit reads these ‘expectations’ and tests that the database schema is as expected.

If a column is added/deleted/renamed without updating this tests – then it will fail when run.

A similar approach can be taken for other SQL objects – views, sprocs, functions etc.

If you have an existing database – a SQL script is provided that can help to automatically create these tests . to give you a ‘baseline’ starting point.

The following screencast gives a quick overview on how to test SQL tables.

Testing the data returned by a SQL table
A key part of database unit testing is ensuring that SQL objects return the expected data.

For example, when selecting data from a table or view, or executing a sproc.

The sample code below shows part of a C# unit test for testing that the table – AdventureWorks.Sales.SalesOrderHeader – does this.

using System;
using MbUnit.Framework;
using DBTestUnit.Util;

namespace DBTemplate.DatabaseTest.Tests.Tables.Functional
    public class SalesOrderHeader
        string dbInstance = "AdventureWorks";
        string tableTestFileDir = AppSettings.DirTableExpectedResults();

        public SalesOrderHeader() { }

        [Row("testData_SalesOrderHeader", "SELECT SalesOrderID, RevisionNumber, OrderDate, DueDate, ShipDate, Status, OnlineOrderFlag, SalesOrderNumber, PurchaseOrderNumber, AccountNumber, CustomerID, SalesPersonID, TerritoryID, BillToAddressID, ShipToAddressID, ShipMethodID, CreditCardID, CreditCardApprovalCode, CurrencyRateID, SubTotal, TaxAmt, Freight, TotalDue, Comment, rowguid, ModifiedDate FROM Sales.SalesOrderHeader WHERE SalesOrderID BETWEEN 43659 and 43678 ORDER BY SalesOrderID")]
        public void T01_CheckRowsFromSelect(string fileName, string sqlText)
            bool areTheSame = DataSetComparer.Compare(tableTestFileDir, fileName, dbInstance, sqlText);
            Assert.IsTrue(areTheSame, "The dataset returned from the database is not the same as that from the XML file.");

How does this work?

At design time ‘SELECT’ or ‘EXEC’ statements are run against a known set of test data.

The tool – ExportDBDataAsXML – is used to output this data and it is stored as XML/XSD files.

Tests – as above – are then written that compare the actual output of the SQL object to the ‘expected’ XML file.

If they differ – then the test will fail.

So how does this work for the code above?

DBTestUnit has a method DataSetComparer.Compare – that can compare and xml file to the output of database (select or exec statement).

bool areTheSame = DataSetComparer.Compare(tableTestFileDir, fileName, dbInstance, sqlText);

The ‘expected’ XML data created at design time is stored in a file ‘testData_SalesOrderHeader’ – see the variable fileName above.

This is compared to actual data return from the SQL table by running the select statement – see the variable sqlText above.

DBTestUnit compares them and returns true if they are the same:

If the data being returned from the table changes for any reason – eg a data type of a column is changed or the actual row values changes – then the test will fail.

See Testing data outputs from SQL objects for more detail on how DBTestUnit can be used to test this type of functionality.

Round up
This blog has given a very quick overview of some of the features of DBTestUnit and how it can be used to carry out database unit testing.

Other blog will give more detail on how to set up tests for different types of SQL objects.

If you are interested in using DBTestUnit and have any questions then feel free to contact me.