Like many companies that require all access be through stored procedures, we seem to have a lot of business logic locked away in sprocs. These things are just plain hard to tes
One method that I've used is to write a 'temporary' unit test for refactoring a particular stored procedure. You save the data from a set of queries from a database, and store them somewhere where a unit test can get at them.
Then, refactor your proc stock. The data returned should be the same, and can be compared directly against the saved data, automatically or manually.
An alternative is to run the two stored procedures in parallel, and compare the result sets.
This works particularly well for select-only stored procedures, but updates, inserts & deletes are more complex.
I've used this method to get the code to a state where it is more susceptible to unit testing, or simpler, or both.