Unit Testing scalability and performance

My blog has moved.
You can view this post at the following address:
http://www.osherove.com/blog/2004/7/19/unit-testing-scalability-and-performance.html
Published Monday, July 19, 2004 10:34 PM by RoyOsherove
Filed under: ,

Comments

Monday, July 19, 2004 6:47 PM by Me

# re: Unit Testing scalability and performance

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.
Monday, July 19, 2004 8:58 PM by Anatoly Lubarsky

# re: Unit Testing scalability and performance

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.
Tuesday, July 20, 2004 9:38 AM by Philip Nelson

# re: Unit Testing scalability and performance

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.
Wednesday, July 21, 2004 3:52 AM by TrackBack

# TDD with a database - one good solution

TDD with a database - one good solution