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?