Directory.GetCurrentDirectory is C:\WINDOWS\system32

[JamesNK]

Description

When running NUnit tests from VS the result of Directory.GetCurrentDirectory() is C:\WINDOWS\system32, causing tests that load files with relative paths to fail.

Steps to reproduce

1. Get source from https://github.com/codito/Newtonsoft.Json/tree/vs-test-discovery
2. Open Newtonsoft.Json.Roslyn.sln
3. Run tests

Expected behavior

1. Test PerformanceTests.ConvertXmlNode successfully loads the file from the bin directory

Actual behavior

1. System.IO.FileNotFoundException : Could not find file 'C:\WINDOWS\system32\large_sample.xml'.

Environment

Win10
VS2017RC4

[clairernovotny]

This is affecting xUnit as well -- the test host needs to set the directory.

[smadala]

@onovotny When are you seeing xUnit affecting, can you please provide more info, do you see on Debug/Run test?

[smadala]

Able to repro for NUnit3TestAdapter >= 3.2.0, but same test works for NUnitTestAdapter 2.0.0.

NUnitTestProject1.zip

[smadala]

Raised a issue on Nunit side: nunit/nunit3-vs-adapter#303

[smadala]

From nunit/nunit3-vs-adapter#303 (comment)

This actually has nothing to do with the adapters but is a difference between NUnit V2 and NUnit 3. In V2 we guaranteed that the current directory would match the location of the test assembly. In NUnit 3, due to parallelism, this is no longer possible. Use TestDirectory property from TextContext instead.

This is behavior change in NUnit3, using Path.Combine(TestContext.CurrentContext.TestDirectory, "large_sample.xml") solves the issue.

[clairernovotny]

In the past, the host process set the current directory -- dotnet-test-xunit. The adapter never did. We do try to on a "best effort" basis based on the libraries' location, but as noted with NUnit, we can't guarantee it due to running tests in parallel.

That the very least though the test host should set the current directory before invoking the adapter code so we're at a good starting point.

[JamesNK]

This is behavior change in NUnit3, using Path.Combine(TestContext.CurrentContext.TestDirectory, "large_sample.xml") solves the issue.

IMO this is just pushing the problem to the user. The framework should be setting Directory.SetCurrentDirectory and let the user not worry about it.

[smadala]

@onovotny testhost can't set the current directory because it can run multiple test sources at a time.
Setting TestContext is adapter's responsibility. Closing this as won't fix.