Rory - Unit testing and performance testing are two
different things. For perf testing, yes you should
restore the database but NUnit or any other unit testing
tool is not the right tool for it. I think you are in
the right track with your method of rolling back. Unit
tests and scalability test/performance tests are two
different things.
When you talk about database testing performance and
scalability issues you have to deal with blowing up
database and running (some staff you can test only on
the production environment though). You have to deal
with index tuning, transaction log handling, etc. BTW,
there is no need to restore the database just
attach/detach (take offline/bring online). IMHO
rollbacks are not suitable here, they do change runtime
behaviour. Besides, you measure performance mostly on
selects and not DML when you deal with databases.
Yup, I commented on this in your original blog about
this. As our number of tests went up, the time it takes
to run the tests got to the point where developers were
no longer running all the tests. Using transactions to
rollback as a techniques was the first thing to go as it
added enomous amounts of time to the run.
Currently, I am working on having my dal support mock
objects directly, so support the idea that the details
of how a class accesses data shouldn't be exposed on
thier interfaces, but instead the dal can be manipulated
by the test code to use mocks while in the test
environment. In that way, I can support test data in
files, mock data written in code, very small test
databases that can be restored quickly, and substituting
faster test optimized queries to get expected results.