Post #1,000 in this forum! :)


I'm hitting the same issue as this SO thread from 5 days ago:

http://stackoverflow.com...t-tests-but-not-ncrunch

Specifically, when run by NCrunch, my test has this exception:



Remo (ninject dev, and author of the extension) responded with:



Is this something fixable with NCrunch?

Unfortunately, I tried setting this (on both the unit test project and the class library project it's testing) but it still showed the same problem.

After a bunch of debugging, the root cause seems to be how the Ninject automatic module registration works - specifically, where it looks.

The key bit is in the ModuleLoader class:

https://github.com/ninje...les/ModuleLoader.cs#L77

It searches based on

While running under MSTest or the R# runner, that property points to the 'normal' build output directory for the test project (...\Foo.Tests\bin\Debug)

However, when running under NCrunch, it's somewhere under the NCrunch working directory - in my testing,

Does NCrunch use separate AppDomain's, or are all the test runs done in a single one? In any case, if there's some way to get the AppDomain's BaseDirectory to be a place that has the assemblies used during the test (instead of that output directory), it would at least fix the users of Ninject. :)

Is there some different place it could/should look? I'm not sure Ninject would change behavior since it works for runners like R#, but it's worth a shot. :)

This is VS11 Beta with the April update applied. The version from the cmdline says:



I'm able to repro the behavior starting 'from scratch' (a freshly started VS11 instance, no solution open) by doing these steps:

1. create new unit test project/sln (ctrl+shift+n)
   
2. after it's created, go into 'manage nuget packages' to install ninject.extensions.factory
   
3. add a little bit of code to the UnitTest1.cs that was created as part of the project
   

Here's the full source for the UnitTest1.cs:




in the debugger watch window, I can see that under NCrunch, the AppDomain.CurrentDomain.BaseDirectory is C:\Users\james\AppData\Local\NCrunch\20468\4\TestResults\965f4516-9da1-4433-9b75-3b3d1dd933c7\Out

Hi James,

Sorry - I've just re-read my post and realised that I didn't make it completely clear what I was asking.

NCrunch sets the base directory to be equal to the MSTest working directory exactly as you've described. This is by design and is exactly as you've described it. It also is (in some manner of perspective) a source for the Ninject problems.

When testing MSTest tests using the Visual Studio test runner, I observe behaviour identical to the above. MSTest in VS2010 appears to set the app domain base directory to its working directory (the 'Out' dir). This means that the behaviour of MSTest and the R# test runner are not consistent.

The reason Ninject is working under the Visual Studio MSTest runner is because the Visual Studio MSTest runner copies ALL the build output files into the 'Out' directory prior to a test beginning execution. NCrunch currently does not.

So it seems to me that the correct fix to this would be to change the NCrunch test runner so that it copies the build output files in the same manner as Visual Studio's MSTest runner, thus making the behaviour consistent.

Something you can try which may allow you to work around the problem (though I'm not sure as to its technical messiness/feasibility) is to place DeploymentItem attributes for build outputs on tests that are using the Ninject framework to resolve dependencies. If nothing else, this should help to confirm the above. For example:

[TestClass]
[DeploymentItem("ThisExecutingAssembly.dll")]
[DeploymentItem("AnotherAssemblyThisDependsOn.dll")]
public class MyTestClass
{
[TestMethod]
public void MyTest()
{
... Insert normal ninject-dependent test code here ...
}
}

.. This will instruct NCrunch's MSTest runner to copy the build output files into the 'Out' dir along with other MSTest dependencies, thus emulating the normal VS MSTest behaviour.

awesome, thanks!

It's probably a bad idea for lots of reasons, but just to throw it out there, I wondered if the first time during a given run (inside a given VS instance) you could run a 'fake' test in the framework being used (didn't do any asserts, just ran and sent you back some info) to tell you things about the test environment (BaseDirectory for this case, but potentially also things like assemblies loaded as well) and then use those as a guide on what NCrunch sets.

At least the theory would be that you then wouldn't have to keep up with what each framework does (especially if it varies by version or over time), you'd just need to potentially add to the set of things you 'inspect' in order to mimic the existing framework.

Just a thought, and like I said, most likely a very bad one. :)

actually, I would think (hope?) that the frameworks will all have a big change upcoming with pervasive async. MSTest has already started supporting it, but I'd imagine there will need to be more test framework support for things that orchestrate or start multiple async operations (Task or otherwise). Guess we'll see :)