Database unit testing patterns

Each time I create a new SQL object, whether it’s a new table, view, sprocs etc, I find that I follow a similar pattern.

It can be outlined as follows:

1. Write a test to ensure the object exists.

2. Write a test to check the SQL objects properties eg columns in a table, parameters in a sproc.

3. Write a test to check the functionality of the object eg a view returns the expected data.

4. Write a test to check the expected permissions on the object.

After each ‘test step’ – code/script is written so that the tests/requirements are met. The steps have been written in a linear fashion – but usually there is a large degree of iteration between them – especially 2 + 3.

I find that thinking about these 4 steps acts as a really good ‘aide memoire’ and helps ensure a more systematic approach is taken when carrying out database unit testing.

Over the next few weeks I am going to write a series of blogs on how to take a TDD approach to database development – and I will refer back to the steps in this database unit testing pattern.

What do you think?

Do you follow a similar approach to database unit testing or do you do something different?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: