Trouble with NUnit when determining the assembly's directory

Question

I've just started to work with NUnit in order to provide some test coverage for my projects.

Within my main library.dll I need to load up configuration data from an external file that goes with the library, library.xml.

This works fine when I'm using the library, because I use the following to get the directory in which to look for the config file:

string settingspath = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

The problem I've noticed is that when I'm unit testing with NUnit, it copies my assemblies to a Shadow Copy, but doesn't take any of the other files with it, so of course my init fails due to missing config files.

Should I be doing something different to locate config files from within my library? (it's a server app, and I don't want to use the standard app settings, or user's local settings, etc)

Curdle

I suppose that as it's a library, I should possibly have all this sort of stuff externalised by properties, but the problem is that my dll requires various (external) files to be present in an app-relative location. – Curdle

Answer 1

When unit testing it is generally recommended to avoid external dependencies such as the file system and databases, by mocking/stubbing out the routines that call them - that way your tests are more localised, less fragile and faster. See if you can remove the dependencies by providing fake configuration information.

Lore

Though this answer is marked as correct, I find that Gishu's answer at the bottom is better because it allows to determine the assembly's compiled location instead of its shadow copy location. That was the right answer for me anyway, and is in line with NUnit guidance (nunit.org/index.php?p=optionsDialog&r=2.4). – Chickasaw

As a comment I'd +1 this remark, as an answer it's not helpful to me though (I'm using NUnit to run some integration tests, for better or for worse, and this answer does not help me get that to work). – Duplication

Answer 2

Use can use TestContext.CurrentContext.TestDirectory as mentioned by Charlie Poole from NUnit here:

The need to access files in the same directory as the test assembly is the most commonly cited reason for disabling shadow copy. However, this is spurious.

NUnit doesn't copy any assemblies: shadow copy is a function of .NET itself. Consequently, the problem needs to be viewed as "How can I access the file where it is?" rather than "How can I get the file copied to where I think it should be?"

There are three ways to locate a file that is located in the same directory as the assembly:

1) Use Assembly.Codebase - this will give you the location as a URI, which you must then tranform to an appropriate path.

2) Use the current directory, which NUnit has historically set to directory containing the executing test assembly. However, this may not be true for future releases.

3) Use NUnit's TestContext.CurrentContext.TestDirectory, which is the available in the most recent releases.

All of these approaches actually use Assembly.Codebase under the covers, with NUnit doing the work of tranforming the URI correctly in #2 and #3. The common approach of using Assembly.Location is incorrect, unless you actually want the location of the shadow copy cache.

Auster

^^^^^ THIS IS THE RIGHT ANSWER ^^^^^. Nunit already does the work of converting Assembly.Codebase to a path for you – Spic

This doesn't work if you want to use the current directory to enumerate test cases since TestCaseSource has to refer to a static property/field/method now. At the point where it's evaluated, TestContext.CurrentContext is not set. – Helban

Very handy, keeps the test clean – Supersensitive

I've taken the liberty to add the content of the link in your answer, it's valuable information and provides some context. – Emanuel

Answer 3

For using reference files in my Unit Tests, I use Assembly.Codebase which works even if Shadow Copying is turned on. You might want to give it a try..

It returns a string in the Uri format.. so you'd need to create a Uri instance from the codebase string and use Uri.LocalPath to get the actual folder path.

However for production code, the BaseFolder should be retrieved from a well known place (e.g. a Registry key set via the installer on Windows). All file lookups should be rooted from this baseFolder.

Somewise

For anyone else reading this, see Jeff Lewis' answer below. Newer versions of Nunit do this better – Spic

Answer 4

Even if shadow copying is active, AppDomain.CurrentDomain.BaseDirectory points to the original location of the test DLLs.

However, if you can embed your test data as resources in your DLL it's much safer, since there's no extra files that can get lost.

Radiometeorograph

Yeah, trouble is they're config files that I need to be user-editable, and it's the engine.dll that loads it's own config, which is the assembly under test, so it's shadowcopied elsewhere. It smells bad as it is, so I'll move the configuration parameter external so the resulting DLL has no "smarts" of it's own in this regard. – Curdle

Answer 5

you can disable shadow copying on the commandline using the /noshadow switch. Command line options are documented here

Is the external file set to be part of the build of your dll? If you include it in the project and set it to copy always in the Copy To Output in the properties of the file then it should go to the shadow directory I think.

This may help you.

Hamil

Biggest problem with that I've found is that NUnit locks the assembly, so I can't recompile it without unloading the NUnit project. – Curdle

Answer 6

We include the test resource in the test project (in this case in a 'TestData' folder).

In Visual Studio for the resource to access in the test mark

When project builds leaves the image on the 'bin\Debug' folder

and you write the path

string fullImagePath = @".\TestData\vcredist.bmp";

Sematic

Answer 7

As you noted, Assembly.Location returns a useless temporary path somewhere in NUnit's ShadowCopyCache, and this is necessary to avoid locking the file and preventing recompilation.

I had additional problems: first, the NUnit 2 GUI runner doesn't work the same as the NUnit 3 GUI runner (now named TestCentric). Second, I sometimes need to call test methods from another executable. For reference, here are the paths I get:

NUnit 2:

AppDomain.CurrentDomain.BaseDirectory = @"C:\PathToNUnitProject\"
NUnit.Framework.TestContext.CurrentContext.WorkDirectory = @"C:\PathToNUnitProject"
NUnit.Framework.TestContext.CurrentContext.TestDirectory = @"C:\PathToNUnitProject\bin\Debug"

NUnit 3:

AppDomain.CurrentDomain.BaseDirectory = @"C:\PathToNUnitProject\bin\Debug\"
NUnit.Framework.TestContext.CurrentContext.WorkDirectory = @"C:\TestCentric\testcentric-gui-1.2.0"
NUnit.Framework.TestContext.CurrentContext.TestDirectory = @"C:\PathToNUnitProject\bin\Debug"

When the test method is called from outside of NUnit:

AppDomain.CurrentDomain.BaseDirectory = something else entirely
NUnit.Framework.TestContext.CurrentContext.WorkDirectory = Exception
NUnit.Framework.TestContext.CurrentContext.TestDirectory = Exception

For me the solution is: use NUnit.Framework.TestContext.CurrentContext.TestDirectory, as in Jeff's answer, within a try-catch. If it doesn't throw, the returned path will be the same over both NUnit versions.

Cremator

Indeed the solution is to use NUnit.Framework.TestContext.CurrentContext.TestDirectory - the value is consistent between debug run in Visual Studio and nunit console execution. – Licit

Answer 8

Encountered the same problem ... following is my workout:

Before the SUT run, update AppDomain's Base Directory in this way....

String root_path = "{{your path}}";
AppDomain.CurrentDomain.SetData("APPBASE", root_path);

Nazarene