In our company we're currently porting a site from old ASP Classic to ASP.NET 2.0. It's virtually a total overhaul, as we're embracing an object-oriented design that we believe will enable us to scale and maintain the application better.
I just noticed that it's kinda hard to do test-driven development on something that's very much database-driven. Most of our business logic (e.g. cart operations like adding an item to a cart) are done in database stored procedures. And they're actually already done, meaning our ASP.NET app right here is pretty much just a face on top of the business logic layer which in turn appears to be just a thin facade over the database.
What I've discovered to be productive is...TDD purists beware...doing NUnit test classes (test fixtures) that talk to the actual database. I've advocated the use of mock objects, but in this case I've observed that I was able to work faster when testing the actual DAL classes instead. I reckon this is because most of the stuff I'm coding right now are only data retrieval operations. Maybe I'll revert to using mock objects when I'm already doing the things that really perform inserts/updates on the database. In the meantime, I'll have to deal with running unit tests a bit slower than usual -- oops: not actually unit tests but
integration tests. Having this kind of test code is, in my opinion, better than having no tests at all...