Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Building Sql Server Database for each test
nguyette
#1 Posted : Tuesday, May 08, 2018 3:24:29 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 5/8/2018(UTC)
Posts: 8
Location: United States of America

Thanks: 2 times
Was thanked: 1 time(s) in 1 post(s)
In order to let tests that depend on a database run concurrently, is it a good idea to programmatically build the database on test start and tear it down on test end?
Remco
#2 Posted : Tuesday, May 08, 2018 10:22:29 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,178

Thanks: 687 times
Was thanked: 827 time(s) in 787 post(s)
Hi, thanks for posting.

This can be quite a complex area, depending on the number of tests involved and what you are trying to achieve.

Building and tearing down a database for each individual test can be very expensive and will greatly increase the length of your test run. It will work, but there are probably better solutions.

A simple option is to just have one test database created and mark these tests with ExclusivelyUsesAttribute to limit their concurrency.

The best option is usually to have one database for each test process. In this way, concurrency isn't an issue and the databases will only be created when a test process is spawned. This takes some infrastructure to implement. It involves doing the following:
1. Every test interacting with the database needs to check for the existence of the database prior to executing further code. If the database doesn't exist, it is created
2. Databases are created in a way that is programmatically derived from the Process ID of the test process. In this way, the database name is tied to the test process and can be identified by it
3. You need a mechanism to clean up old orphaned databases that do not have a corresponding test process currently running on the machine. You can do this by pulling up the list of databases and reconciling this with the list of running processes on the machine. I recommend doing this when tests begin their execution rather than as a cleanup step, since there is no guarantee a cleanup step will run under edge cases (i.e. stack overflow, out of memory, power outage, etc).

The above approach has the nice advantage that the database is left over at the end of the test run, allowing you to examine its state to help with troubleshooting failed tests.
Users browsing this topic
Guest (3)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.021 seconds.