Very interesting. Yet this raises a lot of questions:

1. IMO a very big problem with database unit testing is its sheer slowness:

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/23/controlling-the-number-and-size-of-unit-tests.aspx

How does an SP call

EXEC dbo.TestEquals 1.5, @MyVar

perform compared to an inline expression such as

SELECT CASE WHEN 1.5 = @MyVar THEN ... ELSE ... END

2. I see that 11 tests ran for 1 second. How much of that was setup/teardown? What time would it typically take to run 1000 tests?

3. When you cannot rollback, have you considered restoring from a snapshot:

http://www.simple-talk.com/sql/t-sql-programming/close-these-loopholes---testing-database-modifications/

4. To separate production code from test, have you considered moving test code to a separate schema and or separate database?