I think tooling is a large part of the problem but I also think there are some fundamental differences between database and middle tier development that make unit testing much harder for database developers.

E.g. I want to test that an order behaves a certain way. If I'm developing my middle tier Order object I simply create an Order mock, including appropriate mocks of any entities it depends on, feed that into my test and I can reliably run it and expect the same result every time. If I'm a database developer I must create an Order record, along with any dependent entity records and run my test against that. 1. The overhead of creating and tearing down that test data is much higher (at some point I'll be tempted to pre-create a whole dataset to run all my tests again, it will be brittle as heck and will be constantly out of synch with the actual tests as more requirements require change in the dataset) and 2. Unless I run all my tests in serial - which is very inefficient - I cannot guarantee that my test will run in isolation from other tests. Some other test, which happens to count the number of orders, at the same time as my test ran will now fail.

Another issue is that database code tends to benefit from being a bit monolithic. e.g. Database respond a lot better to big set based queries with several where filters than they do to big loops with lots of individual If statements. But unit testing works better against small bits of logic. I want to be able to test each of those if separately. My DBA, quite rightly, wants a single, well formed query that he can optimise.

I'm a firm believer in all things Agile and I tend to proselytise about it but I do recognise that it's a much harder problem to crack at the database level than it is for the middle tier (which is where I spend most of my time these days).