Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I am working with EntityFramework 6 code first approach and SQL Server 2014 Express. However, the DBMS may change in future.
That setup allows easily to create a database and add some dummy data for unit tests. Currently, I am creating one database per unit test and drop it after the unit test finished.
I am not sure if creating / dropping a database is such a lightweight operation as creating / deleting a file... So are there any disadvantages with that approach?
The first thing to note is that, if you are creating and dropping DBs as part of your tests, then they aren't unit tests; they're better described as integration tests.
Pedantic point aside, then the key question is, does each test create a different DB, thus can the tests be run in parallel? Or could two tests running at the same time interfere with each other (eg by one dropping the DB half-way through the other's test)?
If they can't run in parallel, then you aren't getting a good return on the time investment of having each test do its own setup and teardown. If you moved this to the test suit setup and teardown functionality, then you'd suffer no new conflict issues between tests and you'd speed up the individual tests.
If they can be run in parallel, then it comes down to a choice. Having each test create and destroy its own DB is cleaner, but it's slower. So take your pick between the two.
It is going to be slow, this is the major disadvantage. It might not be a problem if you have a dozen tests, but when you have hundreds it might be a real problem.
I am not sure if creating / dropping a database is such a lightweight operation as creating / deleting a file...
It's certainly not. A file creation/deletion (whether local or remote) would normally be much faster.
I think speed of unit test execution is your issue here (and it may be fast enough that it doesn't worry you). Normally you want your tests to be fast enough to run repeatedly and not form a bottleneck to your development/deployment. If you're able to turn these databases around quickly enough then it's not a a problem. However if you're going to continue to add such cases, then scalability will become an issue, and I would look at (say) initialising a database per test suite or similar.
