I've implemented a simple mechanism to put data into the database. It just creates entities and stores them to the database. This avoids maintaining of sql scripts. In tests, we have mostly individual data and store only what we need.
If you really want to run them in a sql server, I would run them in different catalog (or "schema" or "database" or however it is called next time). For that reason, you can implement a connection pool, where every test gets another database when requesting a connection, and after you run out of catalogs you let it wait using a lock statement until another test releases one. Isolation is important in tests. If they fail because of some interaction coincidence, you've probably found an issue, but you can't do anything because you can't reproduce it. Limit testing strictly to things that are reproducible else it will drive you crazy. On 8 Sep., 08:34, "Bruno Wouters" <[email protected]> wrote: > I tested sqlite before but it is quite difficult to get our 'start' database > converted to a sqlite one. I could indeed get the scheme there with the > Scheme Export function but we have some default data that also needs to be > in this test database. > > Currently I'm testing IsolationLevel.Snapshot and allowing snapshot on sql > server in combination with running 4 threads at the same time (==cpu core > count). This seems to work great locally but on our teamcity server it is > just as slow as before. I'm still figuring out what could be the cause of > this. > > Thanks for the replies! > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > > Of Stefan Steinegger > Sent: dinsdag 8 september 2009 0:03 > To: nhusers > Subject: [nhusers] Re: Run unit tests in parallel without db deadlocks? > > We are also running unit tests using SqlLite in memory. We create the > database before every test (just open the connection and use Schema > Export) and it is very fast. > > We can switch to sql server by changing the build configuration. Then > it has a database for each test assembly, which is created once, but > tables are dropped and created before each test. This is quite slow, > but we rarely run tests on sql server. > > On 7 Sep., 16:50, Jason Dentler <[email protected]> wrote: > > Bruno, > > Run each test against its own copy of the DB. You don't even need to > > rollback the transaction - just delete the copy. > > > This works great if you can test with a lightweight RDBMS like SQLite. If > > you absolutely must test against something "heavy" like SQL Server or > > Oracle, this probably isn't a reasonable solution. > > > Jason > > > On Mon, Sep 7, 2009 at 7:13 AM, Bruno Wouters > <[email protected]>wrote: > > > > Hi all, > > > > I would like to speed up our unit test run by letting two tests run a > > > the same time. But running two test threads at the same time causes > > > deadlocks on the database. Every test is contained in a transaction > > > and is rolled back at the end of the test(using > > > ISession.BeginTransaction & ISession.Transaction.Rollback). The > > > isolation level is readcommitted. > > > > I was wondering if it is possible to prevent any locks on the > > > database. No test should/will never see data of another test because > > > it is always rolled back and never committed. > > > > Is something like this possible? > > > > Thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
