Our group has been doing unit testing on backend objects for about 2 years now. We require at least one unit test on each simple database object and on stored procedures the objective is to excercise all lines of the code which may require 3-10 tests depending on complexity. A performance test (response time) is require on all objects.
We are using Visual studio Team System Database Edition.
We think unit testing has important benefits, however, those benefits are not what we expected them to be when we started this practice. Our unit tests rarely find defects in the logic as written. Finding logic errors was why we originally thought we should be doing this.
What we found out was that unit tests help us to produce better code for other reasons. The first is by improving design accuracy. This occurs because our standard is to develop the test logic in advance of writing the module. We confirm how we are going to test by quickly showing some syntax in our stand-up meetings with other team members. By communicating how you are going to test something before you start building it you are forced to clarify your objectives and vision of the handshake with other tiers of the application. Before we followed this practice we inevitably ran into surprises because our team did not have a shared vision of how a backend component was going to supply a web service or the UI. We sometimes had to recode or rejig other tiers to adapt the design. The code today has a cleaner design with fewer data manipulations on other tiers.
The second main benefit is on production maintenance. Because the VS team system allows tests to be easily automated, we run the unit tests all the time and this helps find regression errors which have arisen from changes. A simple change such as changing a column from mandatory to non-mandatory may cause a procedure to fail because it was written with another assumption. The existence of unit tests along with good (and random) data generation allows the team to quickly and inexpensively conduct a round of testing that would be far too expensive to repeat manually for each change. Without unit tests, finding problems would typically wait until the unit acceptance test phase. Today we find them early and the quality we release to UAT is better.
Creating unit tests is more work and slower-up-front but our view is that in the long-run time is saved. Like most disciplines the more you do it the quicker you get at it.