Friday, May 21, 2004
Hitting the Remoting barrier.

Over the last few days, I have started to prepare MbUnit to support loading of test assemblies into separate domain. This feature is very important for a number of reasons:

  • test assemblies are shadow copied,
  • test assemblies can be unloaded. This means that MbUnit can detect when you have recompile the test assembly and reload it.The assembly unloading feature is very important if you plan to do Test Driven Development (test, code, test, code...).
  • it is easier to control the AssemblyResolve event,

Of course, executing the tests in separate AppDomain has a big drawback: test results and notifications is transmitted by Remoting, and this cost cpu cycles. Currently there is a big performance hit (twice slower) for using separate AppDomain. A possible explanation is that there too much event notification that need to cross Remoting channel.

To be continued...

posted on Friday, May 21, 2004 9:02:00 PM UTC  #    Comments [4]
Tracked by:
"ladder golf rules" (online) [Trackback]
Monday, June 06, 2005 6:00:45 PM UTC
Why not load your test running code into the separate app domain? So you could simply remote a call like DoAllTests(). This makes for a less chatty interface across the boundary. You could use async event sinks to send notifications to your GUI so that it can update progress indicatiors etc.
John Lam
Monday, June 06, 2005 6:00:46 PM UTC
The test running code is in fact in the separate AppDomain. The communication are for the GUI.
Jonathan de Halleux
Monday, June 06, 2005 6:00:46 PM UTC
It might be not necessary to shadow copy test assemblies and unload the test domain only when they change since it should be easy enough to create a new domain, load assemblies, run test, and unload the new domain in a sequence when the user starts to execute the tests. Unlike some other situations where shadow copying and "smart" domain unloading is necessary unit testing is based around very specific and relatively short-lived "unit of work," i.e. test execution. If you think of a most common usage scenario I think it would go like this: fire up the test GUI, run tests, go change code in the IDE, recompile, re-run the test. Unloading the test domain after tests have been completed should make for a much simpler solution and would allow developers to compile at will between test runs. What do you think?
Sanin
Monday, June 06, 2005 6:00:47 PM UTC
> fire up the test GUI, run tests, go change code in the IDE, recompile, re-run the test.
<br>
<br>This is typically the kind of thing that <a title="" href="http://weblogs.asp.net/nunitaddin/" target="_blank">NUnitAddIn</a> is made for. Did you already try the latest version ? In the latest version, you can right click on a test method and launch it. No need to for gui, you target 1 single test, and it's totally integrated into the VisualStudio. This is really a killer feature for the write test/write code/write test/write code iteration.
<br>
<br>Btw, you are right about shadow copying. Maybe giving the choice to the user of the strategy is better (shadow copying or immediate unloading).
Jonathan de Halleux
Comments are closed.

Page rendered at Thursday, July 24, 2008 5:16:04 AM UTC