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
A colleague swears by the TSQLUnit testing framework. May be worth a look for your needs.
That seems like a terrible policy. Perhaps you can write a stored procedure that executes SQL and begin to transition your code to run through there.
In any case, I would test calling the stored procedures via a traditional automation framework. As the gateway between the application and the data, these should be handled as integration tests, rather than pure unit tests. However, you can use an xUnit based unit testing framework to drive them. As long as your tests have access to run SQL against the database, perhaps through the method I mentioned previously, you should be able to assert that the correct changes were made.
One challenge is that you indicate they are getting lengthy. I would recommend breaking them into subroutines and making them as small as possible. It makes it easier to test, and easier to maintain.