Open GoogleCodeExporter opened 9 years ago
NOTE: My issue looks somewhat similar to Issue #557, but not exactly the same.
I do run CCNET as a service, and the exceptions look similar.
However, I am not writing anything to the Console stream in any of my code (I'm
not sure about whetehr Watin, etc. are though).
And I am definitely not using .NET impersonation. The closest thing I am doing
to impersonation is running the CCNET service using my own domain account as
the service identity/user.
Original comment by justin.w...@gmail.com
on 8 Jun 2010 at 9:58
Have you tried running the tests in-process? e.g. IsolatedAppDomain.
Original comment by grahamr...@gmail.com
on 16 Jun 2010 at 4:10
Update:
Using the following in my scripts, I was able to successfully execute the Watin
tests that previously caused failure:
<gallio runner-type="IsolatedAppDomain" ... />
<ncover profiledProcessModule="nant.exe" ... />
However, running the tests is EXTREMELY slow now. I also tried using these
settings, and got virtually identical slow execution:
<gallio runner-type="IsolatedAppDomain" ... />
<ncover profiledProcessModule="" ... />
In fact, for the test project that contains the Watin tests, most of the test
execution time is unnaccounted for by the tests themselves. For both of the
above-mentioned test runs, I got results similar to this:
Entire UI test project:
Results: 6 run, 6 passed, 0 failed, 0 inconclusive, 0 skipped
Duration: 485.47s
Assertions: 15
RemindersFixture class (total of four tests): Duration: 63.12s, Assertions: 3.
DefaultFixture class (contains 2 tests): Duration: 422.30s, Assertions: 12.
-DefaultFixture Test#1: AssemblyTest_SmokeTest: Duration: 86.92s, Assertions: 2.
-DefaultFixture Test#2: BasicPageSmokeTest: Duration: 2.30s, Assertions: 10.
As you can see, the tests in the DefaultFixture only took about 90s to run, but
the fixture itself is listed as having taken 422s, which is very worrisome
since I have almost all of my tests and fixtures disabled right now while I was
debugging the Gallio issue.
I also attempted to use these settings, but they resulted in test failures of
certain non-Watin tests which prevented the execution of any of the Watin tests
(due to DependsOn attributes), so I didn't attempt to (apparently caused by
failure to read test config settings from the test projects' app.config files):
<gallio runner-type="Local" ... />
<ncover profiledProcessModule="" ... />
Is this extremely slow run speed problem a known side effect (or consequence)
of using the IsolatedAppDomain? Are there any possible solutions or
workarounds, or even ways to figure out what is causing the unaccounted for
execution time?
Thanks.
Original comment by justin.w...@gmail.com
on 17 Jun 2010 at 1:11
Thanks for following up with your fix. I was having issues with an exception
in the MSTestAdapter failing on pinging a host (I have ICMP blocked). Setting
the MSBuild task to a runner type of "IsolatedAppDomain" resolved the issue.
My target now includes this:
<Gallio RunnerType="IsolatedAppDomain" Verbosity="Debug"
Files="@(TestAssemblies)"
IgnoreFailures="true"
ReportDirectory="Reports"
ReportTypes="html">
<Output TaskParameter="ExitCode" PropertyName="ExitCode"/>
</Gallio>
<Error Text="Tests execution failed" Condition="'$(ExitCode)' != 0" />
Original comment by james.sc...@gmail.com
on 8 Mar 2012 at 6:06
Original issue reported on code.google.com by
justin.w...@gmail.com
on 8 Jun 2010 at 9:53