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)
you can disable shadow copying on the commandline using the
/noshadow
switch. Command line options are documented hereIs 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.
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.
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:
NUnit 3:
When the test method is called from outside of NUnit:
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.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.
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.
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