Same AppDomain and TransactionScope

Oct 8, 2010 at 6:01 AM

Hi, for our Unit testing we want to enable a TransactionScope around all the work that is done so that we can roll back before the next.

Looking at the documentation on TransactionScope we can use a DependantTransaction in different Threads, the only problem we have at the moment to get this to work at the System level tests is that Cassini is running in a different AppDomain and I haven't found a way to get the DT across the boundary.

Could CassiniDev be made to actually run in the same AppDomain as the instantiating code?

Coordinator
Oct 8, 2010 at 6:28 AM

CasssiniDev, when used as a library, does execute in the same AppDomain and errors will be propagated to your tests. I am not privy to the  transactional implications in your scenario.

Whether you run Cassinidev in-proc or out-of-proc,  the SimpleWorkerProcess that is created for each request has it's own AppDomain. There is no way around that.

Using CasssiniDev-lib gets you as closer to the metal than you will get with any other server/technique but again, the request will be in a new appdomain.

But if I might make an observation that may provide a different perspective:

A unit test should be simple and atomic. One test should not depend on the final state of another.

Employing transactions to manage test context state seems to be adding unnecessary complexity. 

What is the difference between simply setting up the context for each test and the technique you describe?

If I have misunderstood, please let me know.

 

Oct 8, 2010 at 10:06 AM

Just to clarify a few points:

This is an integration test rather than a Unit test, but even in this scenario each test is atomic. The tests all run perfectly well, but I am looking to boost speed of the test, and a solution is to use transactions.

To do this, I believe that I need to get the controller (MVC) to run inside a DependentTransaction created from the TransactionScope created within the test. According to the documentation this will work across Threads.

But, I need to gain access to the entry point of the Controller action to create the transactionScope, but I also need to get access to the Test. From what you are saying, the Request runs in a seperate AppDomain, so this might not work. If I can pass parameters across though, this may work after all.

Jun 23, 2011 at 9:42 AM

Dewy did you get any further with this? I am in a similar situation with our integration tests where in order to keep our tests atomic any data changes made during an individual test need to be rolled back. We use database projects to push out a copy of the database and this takes a few seconds. If we have to do this for each test the suit of tests will take a long time to run. Rolling back all the data changes would speed up the tests considerably.

Jun 23, 2011 at 9:49 AM

Sorry bronumski, I left this one alone a while back as I didn't have too much time to spend and some of the classes that I wanted to be pass across the domains were not serializable.

Would love to hear if you have any more thoughts on the approach for this?

Our system integration tests take about 3s each to run, although, when we last profiled, it wasn't the db create that was causing the problem, it was the browser interaction that was slowest (used Watin). And this is also why we stopped investigating.

Sorry that I can't be of more help