It's difficult to write tests for an application which uses a database as its persistent store if you have a rule that you can't access the database.
One application I'm working on currently has about two hundred tests. Each test which accesses the database takes around a tenth of a second. Running the suite takes twenty five seconds.
Each of the database tests' SetUp methods contacts SQL Server, creates a new database with an unique name, builds the structure of the database using a script, then populates the database with enough data for the test to run. TearDown simply drops the test database.
Many of the tests access the filesystem.
I run my suite of tests approximately once every ten minutes. I can let the tests run while I carry on working (I use TestDriven.NET) or, as I do more usually, sit back and decide what to do next.
I think it's fine for a test run to take a minute or even two, so long as it can be done in the background. Any longer and it might feel like you weren't getting the quick feedback you want. If you've broken something, you don't want to have made five minutes' worth of edits before you discover it.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
101112131415161718
|
»
]
Previous Topic
