We’ve found that the unit tests we’ve written for our C#/C++ code have really paid off. But we still have thousands of lines of business logic in stored procedures, which only really get tested in anger when our product is rolled out to a large number of users.
What makes this worse is that some of these stored procedures end up being very long, because of the performance hit when passing temporary tables between SPs. This has prevented us from refactoring to make the code simpler.
We have made several attempts at building unit tests around some of our key stored procedures (primarily testing the performance), but have found that setting up the test data for these tests is really hard. For example, we end up copying around test databases. In addition to this, the tests end up being really sensitive to change, and even the smallest change to a stored proc. or table requires a large amount of changes to the tests. So after many builds breaking due to these database tests failing intermittently, we’ve just had to pull them out of the build process.
So, the main part of my questions is: has anyone ever successfully written unit tests for their stored procedures?
The second part of my questions is whether unit testing would be/is easier with linq?
I was thinking that rather than having to set up tables of test data, you could simply create a collection of test objects, and test your linq code in a “linq to objects” situation? (I am a totally new to linq so don’t know if this would even work at all)
I ran into this same issue a while back and found that if I created a simple abstract base class for data access that allowed me to inject a connection and transaction, I could unit test my sprocs to see if they did the work in SQL that I asked them to do and then rollback so none of the test data is left in the db.
This felt better than the usual ‘run a script to setup my test db, then after the tests run do a cleanup of the junk/test data’. This also felt closer to unit testing because these tests could be run alone w/out having a great deal of ‘everything in the db needs to be ‘just so’ before I run these tests’.
Here is a snippet of the abstract base class used for data access
next you will see a sample data access class using the above base to get a list of products
And now in your unit test you can also inherit from a very simple base class that does your setup / rollback work – or keep this on a per unit test basis
below is the simple testing base class I used
and finally – the below is a simple test using that test base class that shows how to test the entire CRUD cycle to make sure all the sprocs do their job and that your ado.net code does the left-right mapping correctly
I know this doesn’t test the ‘spGetProducts’ sproc used in the above data access sample, but you should see the power behind this approach to unit testing sprocs
I know this is a long example, but it helped to have a reusable class for the data access work, and yet another reusable class for my testing so I didn’t have to do the setup/teardown work over and over again 😉