Nunit: .NET CLI 및 .NET Core에서 `dotnet test` 지원

우리는 #927로 진행하기 전에 .NET Core가 조금 안정되기를 기다리고 있었는데, 이것이 새로운 제목과 정보로 업데이트되지 않은 이유입니다. 앞으로 진행하기 전에 //build에서 발표될 수 있는 모든 발표를 기다릴 계획이었지만 도움을 받을 수 있으면 감사하겠습니다. 내 계획은 .NET Core, UWP 및 Xamarin을 포함하여 올 여름 3.4 릴리스로 더 많은 플랫폼에 대한 완전한 지원을 제공하기 시작할 것입니다.

여기에 잘 작성된 요약을 제공했으므로 #927을 닫고 이 문제를 앞으로 추적하는 데 사용할 것입니다. 이 문제에 대해 도움을 원하시면 조정해 드릴 수 있지만 기꺼이 도와드리겠습니다.

이 프로세스의 첫 번째 단계는 NUnitLite 및 현재 Xamarin 러너와 같은 NUnit 프레임워크의 특정 버전에 밀접하게 바인딩되지 않고 테스트를 로드하고 실행할 수 있는 PCL 드라이버/에이전트를 만드는 것이었습니다. 아직 초기 단계이지만 nunit.portable.agent 프로젝트에서 진행 중인 작업입니다.

@piotrpMSFT 또는 @livarcocc 가 줄 수 있는 모든 도움이나 조언도 감사하겠습니다.

@rprouse dotnet 테스트와 러너 간의 상호 작용 및 요구 사항에 대한 더 나은 문서를 작성하기 위해 CLI에 버그가 있습니다. 오늘 또는 내일 완료하고 여기에 링크를 걸어두겠습니다.

이것은 버그를 추적하는 것입니다: https://github.com/dotnet/cli/issues/1803.

이것은 어떻게 진행되고 있습니까? 이거 써보고 싶은데 dotnet cli 생태계가 안정화되고 있는 것 같습니다.

나는 약간의 진전을 이루고 있지만 RC2가 떨어질 때까지 너무 많은 일을 하고 싶지 않습니다. 나는 변화를 따라가려고 하는 것이 지겹다 :smile:

.NET Core RC2가 릴리스 되었으며 새로운 정보를 사용할 수 있습니다. 참고용 링크.

• dotnet-test 명령
• dotnet-test 통신 프로토콜

제가 도와드릴까요? 이것은 StackExchange.Redis와 같은 일부 포트를 완료하기 위한 차단기입니다.

@NickCraver 확실히 도움이 될 수 있습니다. 통신 프로토콜을 처음 읽어도 상황이 매우 명확

첫 번째 단계는 이 문제에 접근하는 방법을 결정하는 것입니다. 현재 .NET Core를 대상으로 하는 이식 가능한 빌드가 있지만 제한적입니다. 프레임워크의 핵심 빌드를 만드는 것을 고려하고 있지만 필요한지 해야 하는지 잘 모르겠습니다.

그런 다음 dotnet 명령에 대한 테스트 확장을 만드는 데 필요한 사항을 살펴봐야 합니다.

마지막으로 nunit3-console이 .NET Core 단위 테스트를 실행할 수 있도록 nunit 엔진이 핵심 nunit-agent를 실행하고 통신할 수 있기를 바랍니다. 이 작업을 하고 있지만 아직 해야 할 일이 많습니다.

어떻게 도와주시겠습니까?

@rprouse 크로스 플랫폼을 사용하려면 핵심 빌드가 있어야 한다고 생각합니다. 이는 중요한 기능입니다.

남은 작업량을 감안할 때 솔직히 말해서 다른 곳에 투자하는 것과 비교할 때 얼마나 많은 시간을 투자할 수 있는지 잘 모르겠습니다. 현재로서는 라이브러리와 앱을 빌드하기 위해 대기 중인 많은 다운스트림 사람들을 위해 라이브러리를 공개해야 합니다. 이 말을 하고 싶지는 않지만 여기에 있는 지연과 현재 사용 가능한 항목을 고려할 때 모든 것을 xUnit으로 이식하는 작업을 완료해야 한다고 생각합니다. 그렇지 않으면 수백에서 수천 명의 개발자가 여기에서 차단된 릴리스 체인을 기다리고 있습니다.

나는 우리가 안정되고 시간이 허락한 후에 이것을 다시 방문할 것입니다. 그러나 (그리고 내가 틀렸다면 저를 수정하십시오) 지금 우리는 내가' d 이것을 사용하여 완성된 라이브러리 포트를 배송할 준비가 되었으면 하는 바램을 실행할 수 있습니다. 작가의 의무라는 관점에서, 나는 먼저 사람들을 차단 해제한 다음 내가 할 수 있는 한 업스트림을 도와야 합니다.

@NickCraver 가 xUnit으로 포팅하는 데 노력을 NUnit 3을 사용하여 .NET Core 테스트 에서 수행하는 방법에 대해 블로그에 게시했습니다.

나는 몇 가지 개인 프로젝트를 위해 그렇게하고 있으며 기능적입니다.

적절한 dotnet-test-nunit 빌드를 얻을 수 있도록 기꺼이 도와드리겠습니다. 많은 사람들이 혜택을 받을 것이라고 확신합니다. 프로토콜에 정의된 계약의 대부분은 이미 도우미 라이브러리에 구현되어 있습니다. 작동하는 xplat nunit 러너가 있다면 이것은 거의 작업이 아닐 것입니다.

이것을 두 단계로 나누는 것이 도움이 될까요? 일종의 "빠르고 더럽고, 엉뚱한 해킹이 있을 수 있지만, 최소한 뭔가를 꺼내자" 릴리스와 나중에 더 완전한 통합이 이루어집니까?

(예를 들어, netstandard1.3의 TFM으로 테스트를 빌드하려고 하면 Noda Time에 대한 차단을 해제하는 데 큰 도움이 됩니다.)

@jskeet 과 @NickCraver 는 @rprouse가 제안한 것처럼 NUnitlite "hack"을 통해 오늘 NUnit을 사용할 수 있습니다. 저는 Npgsql에 대해 잠시 동안 이 작업을 수행해 왔으며 잘 작동합니다. 완벽한 솔루션은 아니지만 확실히 차단 해제해야 합니다.

@roji : dnxcore50 와 함께 작동했습니다(저는 잠시 동안 Noda Time과 함께 사용했습니다) - 하지만 netstandard1.3 를 사용하면 NUnit 및 NUnitLite에 대한 종속성이 유효하지 않습니다.

@jskeet 내 테스트 프로젝트는 netcoreapp1.0을 대상으로 하며 Nunit+NUnitLite 3.2.1에 의존합니다. 나는 "imports" : [ "dotnet54" ] 있고 그것은 매력처럼 작동합니다...

@roji : 감사합니다... 손가락이 엇갈

@roji : 실제로 테스트를 실행하는 데 여전히 문제가 있습니다. 따라야 할 예로서 테스트 프로젝트에서 이 작업을 수행하는 위치에 연결할 수 있습니까?

@jskeet , 여기 있습니다: https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.Tests

@jskeet 가져

@piotrpMSFT 시간을 절약하고 dotnet-test-nunit 생성을 위한 도우미 라이브러리를 알려 주시겠습니까? 검색할 수 있지만 현재 몇 가지 사항을 추적 중이므로 도움을 주시면 감사하겠습니다. 당신도 바쁘실 텐데, 손에 없으면 시간을 들이지 말고 찾아드리겠습니다.

관심 있는 사람을 위해 NUnit 3 를

@jskeet 에는 project.json에 import 문이 필요합니다. 기본적으로 새 .NET Core 템플릿에 추가되지만 업그레이드할 때 추가해야 합니다.

콘솔 러너의 project.json의 경우;

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }

또는 어셈블리에서;

  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"
    }

RC2로 업그레이드할 때 경로에 오래된 DNX 항목이 있는 것도 저를 물렸습니다. 확인할 사항입니다.

@rprouse : 감사합니다. 이제 빌드할 수 있으며 테스트는 Windows에서 실행됩니다. Linux에서 "개체 참조가 개체의 인스턴스로 설정되지 않음"이 표시됩니다. dotnet run 에 대한 메시지입니다. 더 조사해야 합니다. 동일한 문제가 있는지 확인하기 위해 최소 샘플을 시도합니다...

@jskeet , 우리는 문제 없이 Windows와 Linux 모두에서 이 접근 방식을 사용하고 있습니다. 예를 보려면 여기 와 여기 를 참조 하십시오 .

@oschwald : 예, "Object reference not set..." 문제는 종속성과는 별개의 문제인 것 같습니다. 오류 메시지가 (스택 추적도 없이) 도움이 되지 않는다는 것은 부끄러운 일입니다. 자세히 살펴보고 있습니다.

@jskeet 몇 가지 원인이 있습니다. 이것이 당신의 것입니까? https://github.com/dotnet/cli/issues/3075

@NickCraver : 아니오 -

제 경우에는 다른 프로젝트에 대한 종속성 없이 작동하지만 실패하는 project.json 파일이 있습니다. 완전한 재현을 위해 시간을 더 투자해야 합니다.

@jskeet Gotcha - 관련: https://github.com/dotnet/cli/issues/2469 및 Slack 채널 은 project.json 라이브 디버그에 적합합니다. 예제와 함께 참여하면 일반적으로 꽤 빨리 시작할 수 있습니다. Slack의 경우 #general 및 #dotnet-core 채널이 꽤 활성화되어 많은 사람들이 이 과정을 거치고 다음 사람을 돕습니다.

흠... 이제 작동합니다. @NickCraver가 보고한 것과 동일한 문제 dotnet restore - 문제를 해결하기 위해 잘못된 프로젝트를 수행한 것일 수 있습니다. 어쨌든, 나는 지금 Linux에서 Noda Time 테스트를 실행하고 있습니다. 그래서 yay :) 모두 감사합니다.

@piotrpMSFT 는 포인터에 대한 요청으로 필요한 모든 것을 찾았고 작업을 시작했습니다.

nunit/dotnet-test-nunit#1에 dotnet-test-nunit 주자에 대한 초기 PR을 추가했습니다.

테스트를 탐색하고 실행하지만 여전히 일부 작업, 정리 및 테스트가 필요합니다. 누구든지 가지고 놀고 싶다면 빌드 아티팩트에 대한 NuGet 피드에 더 쉽게 액세스할 수 있도록 만들 것입니다.

Visual Studio에서 로드할 때 NuGet 패키지를 디버깅하는 방법에 대한 아이디어가 있는 사람이 있으면 도움을 받을 수 있습니다. 지금까지는 Visual Studio에서 실행되고 있지 않지만 설정 문제일 수 있습니다.

@rprouse : 유용하다면 Noda Time이 어떻게 대처하는지 보고 싶습니다. 특별히 확인했으면 하는 사항이 있으면 알려주십시오. 모든 작업에 감사드립니다!

아직 본격적인 준비가 되지 않았지만 콘솔과 Visual Studio에서 NUnit .NET Core 테스트를 실행하고 있습니다. 내가 알파를 얻기 전에 해결해야 할 몇 가지 문제가 여전히 있지만, 열심히 작업이 완료되고 세부 사항에 이르기까지 우리는 이제 훨씬 더 가까워졌습니다.

몇 가지 문제를 수정한 후 CI 빌드로 테스트하는 방법에 대한 세부 정보를 게시하겠습니다. 사람들이 타이어를 발로 차고 문제를 찾는 데 도움을 줄 수 있다면 감사하겠습니다.

여기 스크린샷이 있습니다.

@rprouse : CI 빌드에 진전이 있습니까? 확실히 타이어를 걷어차고 싶어합니다. Noda Time은 _합리적인_ 수의 NUnit 기능을 사용하므로 어쨌든 좋은 시작이 될 것입니다. VS에서 다시 테스트를 실행할 수 있기를 정말로 고대하고 있습니다. (Roslyn용 NCrunch 및 CodeRush도 출시되면 지원을 시작하기를 바랍니다...)

@jskeet 및 알파를 출시하기 전에 테스트를 도와주고 타이어를 걷어차는 데 관심이 있는 다른 사람들을 위해 dotnet-test-nunit 분기의 데모 저장소 를 dotnet-test-nunit 러너를 사용했습니다.

nunit/dotnet-test-nunit 리포지토리 에서 문제를 보고하세요.

높은 수준의 지침은 다음과 같습니다.

업데이트: 이제 dotnet-test-nunit 를 NuGet에서 알파로 사용할 수 있습니다. Include prereleases 하세요. 더 이상 nuget.config 파일을 업데이트할 필요가 없습니다.

dotnet-test-nunit 는 아직 개발 중이므로 NUnit CI NuGet 피드에서 NuGet 패키지를 다운로드하려면 NuGet.Config 파일을 솔루션에 추가해야 합니다.

테스트 프로젝트의 project.json 는 다음과 같아야 합니다.

프로젝트.json

{
    "version": "1.0.0-*",

    "dependencies": {
        "NUnitWithDotNetCoreRC2": "1.0.0-*",
        "NETStandard.Library": "1.5.0-rc2-24027",
        "NUnit": "3.2.1",
        "dotnet-test-nunit": "3.4.0-alpha-1"
    },
    "testRunner": "nunit",

    "frameworks": {
        "netstandard1.5": {
            "imports": [
                "dnxcore50",
                "netcoreapp1.0",
                "portable-net45+win8"
            ]
        }
    },

    "runtimes": {
        "win10-x86": { },
        "win10-x64": { }
    }
}

여기서 관심 있는 라인은 dotnet-test-nunit 에 대한 종속성입니다. -CI 끝나는 최신 시험판 버전을 자유롭게 사용하십시오. 이는 master 브랜치의 최신 버전입니다. NUnitWithDotNetCoreRC2 종속성은 테스트 중인 프로젝트입니다.

NUnit 3을 테스트 어댑터로 지정하기 위해 "testRunner": "nunit" 를 추가했습니다. 또한 테스트 어댑터와 NUnit을 해결하기 위해 가져오기를 추가해야 했습니다. 마지막으로 runtimes 를 추가해야 했습니다. 내가 왜 그렇게 해야 하는지 설명할 수 있는 사람이 있으면 알려주세요.

이제 Visual Studio 테스트 탐색기를 사용하거나 명령줄에서 dotnet test 를 실행하여 테스트를 실행할 수 있습니다.

# Restore the NuGet packages
dotnet restore

# Run the unit tests in the current directory
dotnet test

# Run the unit tests in a different directory
dotnet test .\test\NUnitWithDotNetCoreRC2.Test\

경고

내가 말했듯이 이것은 아직 개발 중입니다. 위에 나열된 dotnet-test-nunit 버전 3.3.0.39-CI에는 TestResult.xml 파일을 저장하려고 할 때 ArgumentException 발생하는 버그가 있습니다.

또한 dotnet 명령줄은 빈 줄을 삼키고 색상과 함께 작동하지 않습니다. NUnit 테스트 러너의 출력은 색상으로 표시되지만 볼 수 없습니다.

"빈 줄 삼키는" 부분은 알려진 버그입니다: https://github.com/dotnet/cli/issues/2234

@jskeet 링크 감사합니다. 색상도 알려진 버그인 것 같습니다.

ArgumentException 가 3.3.0.49-CI 에서 수정되었습니다. 위의 지침을 수정 사항으로 업데이트하겠습니다. 또 다른 해결되지 않은 문제는 현재 러너에 테스트의 줄 번호를 제공하고 있지 않기 때문에 Visual Studio 테스트 탐색기에서 테스트를 클릭해도 코드로 이동하지 않는다는 것입니다.

--where 등과 같은 명령줄 인수 지원이 아직 없다고 말하는 것이 맞습니까? (초창기라는 것을 충분히 이해합니다. 이것이 제가 할 수 있는 일인지 확인하려고 합니다.)

나는 당신에게 약간 다른 project.json 를 시도했습니다. 아래에 그대로 포함시켰지만 중요한 차이점은 다음과 같습니다.

• 데스크톱 런타임도 테스트하고 싶으므로 두 개의 프레임워크 대상이 있습니다.
• netcoreapp1.0 대신 netstandard1.5
• "type"="platform" 와 함께 Microsoft.NETCore.App 종속성을 포함했습니다.
• 엄마, 런타임 섹션이 없습니다. (아마도 위의 변경 사항 중 일부로 인해...)

{
  "buildOptions": {
    "keyFile": "../../NodaTime Release.snk",
    "embed": {
      "include":  [   
        "TestData/*"
      ]
    }
  },

  "configurations": {
    "Debug": {
      "buildOptions": {
        "define": [ "DEBUG", "TRACE" ]
      }
    },
    "Release": {
      "buildOptions": {
        "define": [ "RELEASE", "TRACE" ],
        "optimize": true
      }
    }
  },

  "dependencies": {
    "NodaTime": { "target": "project" },
    "NodaTime.Testing": { "target": "project" },
    "NUnit": "3.2.1",
    "dotnet-test-nunit": "3.3.0.49-CI",
    "Microsoft.CSharp": "4.0.1-rc2-24027",
    "System.Dynamic.Runtime": "4.0.11-rc2-24027",
    "System.Reflection.Extensions": "4.0.1-rc2-24027",
    "System.Xml.XDocument": "4.0.11-rc2-24027"
  },

  "testRunner": "nunit",

  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Threading.Tasks": "",
        "System.Xml.Linq": ""
      }
    },
    "netcoreapp1.0": {
      "imports" : [ "dnxcore50", "netcoreapp1.0", "portable-net45+win8" ],
      "buildOptions": {
        "define": [ "PCL" ]
      },
      "dependencies": {
        "Microsoft.NETCore.App": { 
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        },
        "System.Console": "4.0.0-rc2-24027",
      }
    }
  }
}

결과:

Test Count: 15141, Passed: 15141, Failed: 0, Inconclusive: 0, Skipped: 0

우트. (net451을 사용하여 15646의 테스트 카운트를 얻었습니다. 이는 제가 예상한 것입니다.)

다음으로: Linux 시스템에서 동일한 작업을 시도합니다(여기서 project.json은 Linux를 언급하지 않기 때문에 수정 없이는 작동하지 않을 것입니다. dotnet CLI는 다소 협소합니다).

흠. 14분 동안 CPU를 100% 소모한 후에도 Linux에서 테스트가 완료되지 않았습니다. 그곳에서 무슨 일이 일어나고 있는지 더 자세히 살펴볼 필요가 있습니다.

@jskeet

--where 등과 같이 아직 명령줄 인수 지원이 없다고 말하는 것이 맞습니까?

제대로 테스트되지 않았지만 --where 와 대부분의 일반적인 명령줄 매개변수를 연결했습니다. 여전히 문제가 있습니다. nunit/dotnet-test-nunit#4가 모두 제대로 연결되어 있고 작동하는지 확인하고 누락된 항목을 추가합니다. 지금까지 많은 것을 테스트하지는 않았지만 dotnet 명령의 끝에 추가하여 몇 가지를 사용했습니다. 그래도 정확히 어떻게 작동하는지 알아내야 합니다. 예를 들어 --debug 명령줄 옵션은 dotnet-test-nunit 솔루션에서 제대로 작동했지만 테스트 솔루션에서 실행하면 dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" 발생합니다. 또한 지원되는 항목을 표시하기 위해 도움말 명령줄을 우리에 연결하는 방법도 모릅니다.

그동안 https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs 에서 내가 생각하는 명령줄 옵션을 확인할 수 있습니다. 지원:스마일:

아, 예 - dotnet test 에는 테스트 프레임워크에 대한 인수를 dotnet test 자체에 대한 인수에서 분리하기 위한 dotnet run 와 동일한 기능이 없는 것 같습니다. 나는 노력했다

dotnet test -- --help

그리고

dotnet test -- --where=cat!=Slow

그냥 사용

dotnet test --where=cat!=Slow

잘 작동합니다. 이에 대한 기능 요청을 제출할 예정입니다. 완전히 명확할 수 있어서 좋습니다.

테스트를 클릭하고 코드로 이동하는 것은 이제 3.3.0.60-CI 에서 수정되었습니다.

여전히 우선순위가 높은 두 가지 문제가 있으므로 알파 릴리스를 수행할 계획이며 이 시점에서 이 문제를 닫고 새 저장소의 모든 것을 추적할 것입니다. 두 가지 문제는 다음과 같습니다.

• [x] nunit/dotnet-test-nunit#22 실패한 테스트에 메시지 및 스택 추적 추가
• [x] nunit/dotnet-test-nunit#12 TestContext.WriteLine이 TestExplorer 테스트 요약에 표시되지 않음

참고로 오늘 Ubuntu 상자에서 Noda Time 테스트를 다시 실행했으며 약 15분 후에 완료되었습니다. Win10 i7보다 Linux i5에서 모두 5-6배 느리게 실행되는 것 같습니다. 그것이 CPU와 얼마나 관련이 있고 JIT와 얼마나 관련이 있는지 확실하지 않습니다. 그리고 그것은 확실히 NUnit의 범위를 벗어납니다. :)

@jskeet 업데이트에 감사드립니다. 좋은 소식입니다. nunit/dotnet-test-nunit#9에 표시된 대로 Linux 테스트에 모노 바인딩이 필요했습니까?

테스트하는 사람을 위해 최신 NuGet 패키지는 3.3.0.69-CI 입니다. 이를 사용하여 테스트하십시오. 현재 릴리스를 차단할 만큼 심각하다고 생각되는 미해결 문제는 없습니다. 이번 주에 보고된 것이 없으면 이번 주 말이나 다음 주 초에 알파 릴리스를 만들 것입니다. 그렇게 하면 이 문제를 닫고 향후 토론/문제는 dotnet-test-nunit 리포지토리에서 계속될 수 있습니다.

지금 테스트하거나 영원히 평화를 유지하십시오 :스마일:

@rprouse : Mono에서 실행을 시도하지 않았습니다. Linux의 .NET Core 전용입니다. 위의 정확한 project.json에서 잘 작동했습니다.

69-CI에 소용돌이를 줄 것입니다...

이것과 콘솔 앱 러너 사이에 내가 알아차린 한 가지 차이점은 "dotnet test" 버전은 전체 기간에서 테스트를 찾는 데 소요된 시간을 포함하는 반면 NUnitLite와 함께 사용했던 "dotnet run" 명령은 그렇지 않다는 것입니다. . Noda Time에서 이것은 내가 --where=cat==Foo 실행하면(해당 카테고리에 이러한 테스트가 없음) "dotnet test"는 14초의 기간을 보고하는 반면 "dotnet run"은 0.01초의 기간을 보고함을 의미합니다. 둘 다 거의 동일한 실제 경과 시간이 걸립니다.

이것은 의도적인가? 나는 확실히 그 행동에 신경 쓰지 않지만 사람들이 실제로 느리다고 생각하지 않도록 어딘가에 주목할 가치가 있습니다.

@jskeet 좋은 관찰입니다. 실제로 그렇습니다. 테스트를 실행할 전체 NUnit 엔진이 없기 때문에 코드가 더 단순하지만 테스트 실행을 래핑하는 대신 첫 번째 테스트 시작 이벤트에서 시계를 시작할 수 있습니다. 문제를 입력하겠습니다.

https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 의 GitHub에서 dotnet-test-nunit 알파 버전을 릴리스했으므로 더 이상 변경할 필요가 없습니다. NuGet.config 파일을 만들고 CI 릴리스를 사용합니다.

이제 알파가 나왔으므로 이 문제를 종료하겠습니다. https://github.com/nunit/dotnet-test-nunit/issues 에서 알파를 테스트하고 문제를 보고하도록 도와주세요

dotnet-test-nunit 에 대한 추가 정보의 설명서를 업데이트했습니다. 최신 상태로 유지하겠습니다.

https://github.com/nunit/dotnet-test-nunit

이전에 언급했듯이 "Microsoft.NETCore.App" 종속성에 대해 "type": "platform" 를 사용하는 경우 런타임을 지정할 필요가 없습니다. xUnit 문서를 감안할 때 이것이 선호되는 접근 방식이라고 생각합니다.

현재 Travis를 통해 실행 중인 풀 리퀘스트가 있습니다. 녹색이 되면 Noda Time이 이에 의존하므로 _일부_ 사용량을 제공해야 합니다. 수고하셨습니다 선생님...

제가 지금 막 알아차린 한 가지 단점은 제가 더 이상 Linux에서 Mono로 쉽게 테스트할 수 없다는 것을 의미합니다. 나는 그것이 NUnit 문제가 아니라고 생각합니다. 기본적으로 https://github.com/dotnet/cli/issues/3073 의 표현이지만 NUnit에 대한 것입니다. 나는 여전히 그것이 결국 고칠 수 있기를 희망합니다. 잠시 동안 나는 약간의 내키지 않고 Travis에서 내 모노 테스트를 비활성화할 것입니다. ( dotnet test 는 확실히 미래입니다.)