So I was working today on some code that has a fair amount of automagically generated tests. Now I must first say that generated code is cool, but generated tests...not so much. If you claim tests for code coverage...go for it. If it is about TDD, you can't really "generate" the tests can you. (That would be TGD--test generated development) The tests are supposed to come before the code...OK, that's an argument for another post.
The point of this post is that when you are doing tests, you have to be sure of what you are testing. If you are testing data access, test data access. If you are testing workflow, test workflow. But please, please don't try to test that your workflow correctly writes to the database. Your tests take way too long.
For example, if you have an integration test that tests your ORM mappings then fine, you have 4 tests: Insert, Update, Delete, Read. If, however, you have a need to test that a user can't delete a record from the database, do you really need that test to set up a record in the database just to be sure that he can't delete it? A resounding NO. The test should be about validating the permission of the user. Our code generation had blurred the line of what we were really testing and thus introduced tests that interacted with the database, but really had no reason to even think about the database.
Now I get to spend my morning tomorrow refactoring the tests to ignore the database completely and simply set the permissions for the current user and then Assert that the user permissions appropriately allow/deny. 8 seconds vs 3 milliseconds. I know which tests I want to run "red/green/refactor"!
Keep in mind, your tests should follow along with the Single Responsibility Principle. It should test one thing and should not depend on a whole lot of setup to make it happen. That's what mocks, stubs and fakes are for. Keeping your tests lean will keep the time to run them to a minimum. You really lose out on a lot of the advantages of TDD when you generate your tests automatically (including the "right-click" generation in VS2008). The Design in TDD comes from thinking about what you are testing and driving what you code you actually write.