Nunit: 콘솔 NUnit 3의 테스트 작업 디렉토리

이것은 https://github.com/nunit/nunit/wiki/Breaking-Changes에 표시된 대로 의도적으로 설계된 것입니다.

이전 버전에서 NUnit은 작업 디렉토리를 변경했습니다. 더 이상 그렇게 하지 않습니다. TestContext.TestDirectory를 사용하여 테스트 어셈블리가 포함된 디렉터리를 가져올 수 있습니다.

새 URL: https://github.com/nunit/docs/wiki/Breaking-Changes

이것은 많은 테스트를 망칩니다! 왜 바꿨어? 테스트된 앱의 런타임 코드에 작업 디렉터리가 테스트 어셈블리의 위치라는 종속성이 있기 때문에 일부 테스트를 수정할 수 없습니다.

@imakowski 어셈블리 설정에서 현재 작업 디렉토리를 알려진 디렉토리로 설정해

``` C#
[픽스처 설정]
공개 클래스 MySetUpClass
{
[원타임셋업]
RunBeforeAnyTests()
{
var 디렉토리 = 경로.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);
Environment.CurrentDirectory = 디렉토리;

    // or
    Directory.SetCurrentDirectory(dir);
}

}
```

@imakowski 당신은 그것을 제어할 수 없지만 코드/애플리케이션은 설정되는 현재 작업 디렉토리에 의존해서는 안됩니다. 응용 프로그램은 항상 위에서 제시한 것과 같은 코드로 bin 디렉토리를 결정해야 합니다. Windows에는 사용자가 알지 못하는 사이에 현재 작업 디렉토리를 변경하는 여러 API 호출이 있습니다. 귀하의 애플리케이션은 대부분의 경우 정상적으로 실행될 수 있지만 사용자가 귀하의 애플리케이션에서 거의 사용되지 않는 부분을 방문한 후에는 실패합니다.

@rprouse 이 코드는 섀도 복사 모드에 있을 때 작동하지 않습니다.
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);

이 경우 다음을 사용할 수 있습니다.
var dir = Path.GetDirectoryName(new Uri(typeof(MySetUpClass).Assembly.CodeBase).LocalPath);

또는 TestContext.CurrentContext.TestDirectory로 제공합니다. :-)

우리는 특별한 경우를 위해 약간의 조정과 함께 제안된 대로 Uri를 사용합니다.

또는 TestContext.CurrentContext.TestDirectory로 제공합니다. :-)

CurrentContext에는 더 이상 TestDirectory 속성이 없습니다. 나는 nunit 3.6.1을 사용합니다. 내 경우에는 resharper에서 테스트를 시작할 때 잘못된 위치를 가리키는 WorkDirectory만 있습니다.(

TestContext.TestDirectory가 있습니다. 정적 속성입니다. WorkDirectory도 마찬가지라고 생각합니까?

글쎄, Visual Studio 브라우저나 컴파일러 또는 텔레릭 디컴파일러를 사용하여 찾을 수 없습니다.
하지만 nunit 3.5에서 볼 수 있습니다. 무엇이 잘못되었는지 확실하지 않다

내가 틀렸어.

TestContext.CurrentContext.TestDirectory입니다.

그러나 PORTABLE 빌드에는 없습니다.

#if !PORTABLE
        /// <summary>
        /// Gets the directory containing the current test assembly.
        /// </summary>
        public string TestDirectory
        {
            get
            {
                Assembly assembly = _testExecutionContext?.CurrentTest?.TypeInfo?.Assembly;

                if (assembly != null)
                    return AssemblyHelper.GetDirectoryName(assembly);

#if NETSTANDARD1_6
                // Test is null, we may be loading tests rather than executing.
                // Assume that the NUnit framework is in the same directory as the tests
                return AssemblyHelper.GetDirectoryName(typeof(TestContext).GetTypeInfo().Assembly);
#else
                // Test is null, we may be loading tests rather than executing.
                // Assume that calling assembly is the test assembly.
                return AssemblyHelper.GetDirectoryName(Assembly.GetCallingAssembly());
#endif
            }
        }
#endif

3.6.0에는 있지만 3.6.1에는 없습니다.

현재 github repo를 보고 있는데 위에서 복사해서 붙여넣은 그대로입니다.

어떻게든 PORTABLE 빌드를 사용하고 있지 않습니까?

예, 사용하고 있습니다

글쎄, 그것이 거기에없는 이유입니다. PORTABLE 빌드에서는 지원되지 않으며 내가 아는 한 지원한 적도 없습니다. 그러나 나는 PORTABLE 빌드를 사용한 적이 없으며 CI 테스트를 실행하십시오.

감사 해요

디렉토리.SetCurrentDirectory(AppDomain.CurrentDomain.BaseDirectory);

@CharliePoole 과 @rprouse가 말한 것을 종합 하면 실제 코드를

[SetUpFixture]
public class MySetUpClass
{
    [OneTimeSetUp]
    public void RunBeforeAnyTests()
    {
        Environment.CurrentDirectory = TestContext.CurrentContext.TestDirectory;
        // or identically under the hoods
        Directory.SetCurrentDirectory(TestContext.CurrentContext.TestDirectory);
    }
}

전역 초기화의 경우

네임스페이스 안에 위의 논리를 묶지 마십시오. 즉

using NUnit.Framework;
using System;
using System.IO;

[SetUpFixture]
public class GlobalSetup
{
    [OneTimeSetUp]
    public void RunBeforeAnyTests()
    {
        Environment.CurrentDirectory = TestContext.CurrentContext.TestDirectory;
        // or identically under the hoods
        Directory.SetCurrentDirectory(TestContext.CurrentContext.TestDirectory);
    }
}

또한 TestContext.CurrentContext.TestDirectory 에는 코너 케이스를 처리할 수 있는 더 많은 정보가 있는 것 같으므로 typeof(MySetUpClass).Assembly.Location 보다 선택하겠습니다.

그래서 typeof(MySetUpClass).Assembly.Location보다 선택하겠습니다.

Location 는 어셈블리가 섀도 복사된 경우 섀도 위치를 반환하며 일반적으로 원하지 않습니다. CodeBase 대신 Uri 가 반환됩니다.

분명히 TestDirectory 를 사용하는 것이 더 낫지만 해당 속성에 문제가 있는 것 같습니다. #2872 참조, catch할 수 없는 예외가 발생합니다. OneTimeSetup 를 사용하는 경우에도 나타날 수 있는지 여부는 알 수 없지만(그렇지 않다고 가정함) 문제가 해결될 때까지 주의를 기울여야 합니다.