Hi Terry,

Can you share any more information about the life cycle of this .mdf file? Is it a resource that is stored with your solution and deployed into the MSTest working area, or is it a file generated from one of your tests?

If you right click on the failed test in the Tests Window, then go to Advanced->Browse to workspace, can you find this file in the NCrunch workspace?

The new version introduced support for the MSTest variable 'DataDirectory', so I wonder if this might be what is causing the issue. Does removing this value from the connection string and replacing it with an alternative value (i.e. perhaps constructing the .mdf path using the current directory) make any difference?

I'm curious as to why the value NCrunch is placing against DataDirectory is different to MSBuild. Is there any chance you'd be able to get me a capture of the difference in this value between NCrunch/MSTest on your solution? Try adding the following code and running your test using each runner:

Console.WriteLine(AppDomain.CurrentDomain.GetData("DataDirectory"));


Thanks!

Remco

NCrunch will make multiple calls into the same process to run sets of tests in batches. This is necessary in order to perform proper continuous testing, as the priorities of tests can constantly change as the source code is being altered. Unfortunately, this makes impossible the old traditional approach of running all tests from start to finish in a single process. Most tests are are OK with this - but some tests that perform setup actions on each test run without considering the behaviour of NCrunch can experience problems. Usually it's fairly easy to fix these tests using a static flag that is set when the setup code is first run, then compared at each time the code is invoked to make sure the setup code is never called twice.

Have a look at test atomicity for more information on this.

If you're experiencing problems with NCrunch running these database tests in parallel with each other over the same .mdf file, you might want to look at introducing some concurrency constraints using attributes.

Hi Terry,

Sorry, I think I have misunderstood your problem.

NCrunch has no knowledge of databases or of the workings of your source code. It does not manipulate connection strings or anything around how your code connects to the database. Your code is basically just code that is executed under test. There is a line of code in NCrunch that explicitly sets the DataDirectory AppDomain variable to be the working directory of the executing test, it does so in this way:

AppDomain.CurrentDomain.SetData("DataDirectory", <working directory>);

This was added because some people make use of the DataDirectory appdomain value which is automatically set by MSTest. This value is automatically placed into connection strings during connection by ADO.NET, so if for some reason this value is different to that which is normally set by MSTest, then your code will be unable to find the database.

The .mdf file is just a file, treated like NCrunch the same as any other file. Because the file is being shared between tests, you should definitely look into making use of ExclusivelyUsesAttribute if you are using parallel execution for your database tests.

But anyway, the key question here is whether or not the database resource file is being referenced in the place that it exists in the NCrunch workspace.

Try adding the following two lines to your test code, then inspecting the results in the test output:

Console.WriteLine(AppDomain.CurrentDomain.GetData("DataDirectory") + @"\Resources\MdmTestDb.mdf");
Console.WriteLine(System.IO.File.Exists(AppDomain.CurrentDomain.GetData("DataDirectory") + @"\Resources\MdmTestDb.mdf"));

This will tell us whether or not the file is in its expected location in NCrunch's workspace. If you can let me know what the results are from the above two lines, I can help with further troubleshooting.

Cheers,

Remco

Some success. I added the attributes :

[DeploymentItem(@"Resources\MdmTestDb.mdf", "Resources")]
[DeploymentItem(@"Resources\MdmTestDb.ldf", "Resources")]

To the first class in the test project, and that seems to work, however, the ideal solution would be to have the attributes work on the method decorated with [AssemblyInitialize]
but that does not seem to work.

On a further note,
when I add

AppDomain.CurrentDomain.SetData("DataDirectory", dataDirectory);

to a test class method with the [TestInitialize] attribute the class will find and use the Database, however when I do this on the method marked with
[AssemblyInitialize] the classes are unable to find the databases - does the DataDirectory item get reset?

Here is what I have done...
I created a base test class, which all our other DB test classes will inherit from.
[TestClass]
public class RepositoryBaseTests
{
[TestInitialize]
public virtual void TestInitialize()
{
//-- Set the DataDirectory for NCrunch
if (NCrunchEnvironment.NCrunchIsResident())
{
AppDomain.CurrentDomain.SetData("DataDirectory", dataDirectory);
}
}
}

(Made it virtual to support the case where an override may be required.)

That seems to have it licked.