WorkingDirectory during discovery in .NET Core

[mpoettgen]

I'm trying to use the TestContext.CurrentContext.WorkDirectory in a netcoreapp1.0 using the dotnet-test-nunit package 3.4.0-beta-1.

During test run, the WorkDirectory is set just fine. But when I add a parameter with a ValueSource and add a static property that uses the WorkDirectory, tests disappear in the VS Test Explorer. The output of "dotnet test" suggests, that the WorkDirectory is actually null.

While I probably could pass a work directory from the command line, this probably cannot be done in VS!?

[rprouse]

If I am reading this right, you are using TestContext.CurrentContext.WorkDirectory in a ValueSource from a static method. I am pretty sure that CurrentContext will be null because the test is not running at that point, it is during the test discovery phase. If that is the case, then this is an NUnit Framework issue, not a runner issue. @CharliePoole can you confirm?

You could work around this by getting the directory from the running assembly.

[mpoettgen]

Looking at the stack trace:

An exception was thrown while loading the test.
System.ArgumentNullException: Value cannot be null.
Parameter name: path1
   at System.IO.Path.Combine(String path1, String path2)
   at Bobs.PDF.Tests.Reader_Tests.get_TestFiles() in C:\...\Reader_Tests.cs:line 43

I'm getting an ArgumentNullException for the parameter path1 into which I pass TestContext.CurrentContext.WorkDirectory, not a NullReferenceException, so TestContext.CurrentContext is probably not null. That's why I thought it was the runner.

[CharliePoole]

This is similar to issue nunit/nunit#1241, which we fixed, except that it deals with WorkDirectory rather than TestDirectory. WorkDirectory didn't seem to need fixing in this way, since it is the directory to which run results and reports are output.

@mpoettgen you seem to be using WorkDirectory as a location from which to locate input files, which isn't what it's intended for.

@rprouse Getting the directory of the running assembly would give you the equivalent of TestDirectory, not WorkDirectory. However, it's probably what he should be using anyway.

I think there is probably some confusion betweein our term "work directory" and the general terminology "working directory" as equivalent to "current directory." Too late to change it now though. :-)

[mpoettgen]

It does appear that nunit/nunit#1241 describes the use case. I wanted to use TestDirectory, but it's not available on .NET Core for whatever reason and WorkDirectory seemed to be more convenient than trying to find the running assembly, as the GetExecutingAssembly method is not available either.

(If you would want to write the discovered test parameters to your report you'd still need the WorkDirectory to be set properly.)

Shouldn't it be possible to have the TestDirectory on .NET Core or is there anything that prevents this?

[rprouse]

Test directory is not available because of the restrictions of the portable profile. We hope to readd stuff like this with a netstandard version of NUnit

[mpoettgen]

I didn't even realize that NUnit wasn't netstandard because it just worked. Of course that explains why there is not implementation of TestDirectory.

For now I'm using

string testDirectory = Path.GetDirectoryName(typeof(MyTestClass).GetTypeInfo().Assembly.Location);

to get the 'TestDirectory' as a workaround.

Not sure if you want to keep this ticket open to either track that WorkDirectory is not set in the runner or TestDirectory is not available on .NET Core. Thanks for your help anyways!

[jcansdale]

@mpoettgen I think you could use: AppContext.BaseDirectory.

Just in case anyone is tempted to use this in a NuGet package. This doesn't currently mean what you probably think it means. It doesn't quite mean the same as, AppDomain.CurrentDomain.BaseDirectory in classic .NET.

This property returns the base directory of the NuGet package of the calling assembly. You won't notice this when called from a test assembly. It is only obvious when the calling assembly is packaged and deployed. Confusing as hell! (@mwhelan flagged this one up)

They probably intend it to be same as, AppContext.GetDate("APP_CONTEXT_BASE_DIRECTORY") (which I believe does what you'd expect).

[rprouse]

I set this to blocked as it is an NUnit issue, not a runner issue.

[MihaMarkic]

@rprouse Is there an issue filled for TestDirectory in nunit?

[rprouse]

@MihaMarkic TestDirectory is in the new .NET Standard 1.6 version of the NUnit Framework which will be released with v3.6