We have quite a bit of logic in TSQL stored procedures. Being a big fan of automated tests, I started writing automated tests for stored procedures.
I test stored procedures by calling them from a C# project. I make all tests touching the database inherit from a base class the ensures the test is run in a TransactionScope that is never committed. There are several issues related to this:
- The tests are slow compared to tests not touching the database but not much can be done about that I suppose.
- Sometimes I run into FK issues when I want to get the database into the state I need it to be before the test logic is run. E.g. when I need to truncate a table that is referenced by FK you can't do that. I need to get rid of the rows in the referencing table as well.
- Sometimes I need to write a new stored procedure or query to get the database into the state that you need it in. On the other hand I ofter find out I need a similar procedure later for new functionality anyway.
Despite these downsides, I still choose to write tests for stored procedure logic as we have quite a bit of logic in stored procedures. Do you use a similar approach, something completely different (like TSqlUnit) or you don't bother testing sprocs?