Nunit: 새 클론 후 nunit.framework.tests에서 실패한 단위 테스트

에 만든 2018년 06월 25일 · 31코멘트 · 출처: nunit/nunit

방금 nunit의 새로운 클론을 잡고 Windows 10 Professional에서 실행되는 최신 NUnit 3 테스트 어댑터(3.10 with Run Tests in Parallel)를 사용하여 Visual Studio 2017(커뮤니티 15.7.4)에서 솔루션을 열고 "Debug-AnyCPU"를 선택했습니다. "하고 빌드를 누르십시오.

BUILDING.md를 읽은 후 nunit.framework.tests-* 및 nunitlite.tests-*에서 발생하지 않는 모든 오류를 무시해야 하는 것 같습니다.

그러나 게이트에서 nunit.framework.tests-*에서 2개의 실패가 발생합니다.

첫 번째 오류:

Test Name:  TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test FullName:  NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs : line 110
Test Outcome:   Failed
Test Duration:  0:00:00.001

Result StackTrace:  at NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory(String workDirectory) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs:line 112
Result Message: 
Expected string length 34 but was 50. Strings differ at index 34.
  Expected: "C:\\Users\\ace.olszowka\\source\\nunit"
  But was:  "C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20"
  -------------------------------------------------^

소스를 보면 이 값이 동일해야 한다고 말할 수 있는 한 이것이 어떻게 가능했는지 알 수 없습니다( _workDirectory 및 테스트 데이터가 모두 TestContext.CurrentContext.WorkDirectory ). 아마도 내 쪽의 잘못된 구성으로 인해 일종의 경쟁 조건이라고 생각합니까?

두 번째 오류:

Test Name:  StackTracesAreFiltered("WarningInBeginInvoke",4)
Test FullName:  NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered("WarningInBeginInvoke",4)
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs : line 292
Test Outcome:   Failed
Test Duration:  0:00:00.004

Result StackTrace:  at NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered(String methodName, Int32 maxLineCount) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs:line 310
Result Message: 
Multiple failures or warnings in test:
  1) (Warning message)
  2) Expected the number of lines to be no more than 4, but it was 5:

 1. at NUnit.TestData.WarningFixture.<>c__DisplayClass45_0.<WarningInBeginInvoke>b__0()
 2. at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
 3. at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
 4. at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
 5. at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
(end)

나는 이 테스트가 여기서 무엇을 하려고 하는지 길을 잃습니다. 하지만 내 제한된 이해에 따르면 이 코드는 호출 스택의 변경 사항에 대해 매우 민감한 것 같습니다. 이것은 .NET Framework의 최근 변경 사항 때문일 수 있습니까?

또한 NUnitLite.Tests.CommandLineTests에서 모든 단일 테스트 케이스가 실패합니다. 예상치 못한 상황이 발생하면 기꺼이 조사하겠습니다.

빌드가 CI에서 전달되는 것을 볼 때 이것은 아마도 내 쪽의 구성 문제일 수 있지만 BUILDING.md에는 이에 대해 언급된 것이 없으므로 보고서가 가치가 있다고 생각했습니다.

bug normal

출처

aolszowka

👍1

모든 31 댓글

신고 감사합니다! 테스트 탐색기에서 TestCaseSourceCanAccessWorkDirectory 및 CommandLineTests 가 작동하지 않는 것을 확인했습니다. 우리는 그것들을 러너와 병렬 처리로부터 독립적으로 만들 방법을 찾아야 합니다. @nunit/framework-team 아이디어가 있습니까?

두 번째 오류의 경우 냄새 테스트입니다. 그것을 5로 올리는 것이 합리적입니다.

jnm2 에 2018년 07월 02일

👍1

과거에는 사람들에게 NUnit 테스트에 테스트 탐색기를 사용하지 말라고 했습니다. 다른 팀원들은 테스트 탐색기가 많은 사람들에게 테스트를 실행하는 기본 방법이 되었다는 말에 반발했습니다.

테스트 프레임워크를 테스트할 때 유용하지 않은 특정 러너에 대한 충분한 전례가 분명히 있습니다. 테스트 중인 프레임워크를 테스트하는 것은 매우 특별한 상황이며 대부분의 사용자가 겪는 상황이 아닙니다. OTOH, 팀이 원한다면 어댑터를 통해 테스트 탐색기에서 성공적으로 실행할 수 있도록 하는 것을 목표로 삼을 수도 있습니다.

당신이 무엇을 하든, 테스트 탐색기에서 NUnit 테스트를 실행하는 것이 현재 작동하지 않는다는 것을 사람들에게 알려주는 문서를 제출해야 한다고 생각합니다. 그 맥락에서 그들에게 그것이 작동하게 하는 것이 목표인지, 아니면 우선순위가 무엇이든 결정된 것이 아니라고 말할 수 있습니다.

어댑터의 첫 번째 저자이자 프레임워크에 다년간 기여한 사람으로서 저는 항상 NUnit 개발에 테스트 탐색기를 사용하는 것을 비난했습니다. 그것은 여전히 문제에 대한 나의 견해입니다. 젠장, 나는 우리가 지금 CI에서 프레임워크를 테스트하기 위해 콘솔을 사용하는 것조차 좋아하지 않는다!!!

어떤 결정을 내리든 어댑터로 인한 것일 수도 있고 아닐 수도 있는 문제가 발생하면 사람들을 실제 NUnit 러너(NUnitLite 또는 콘솔 러너)로 계속 보내야 한다고 생각합니다. 어댑터는 NUnit 프로젝트에 있더라도 기본적으로 타사 러너와 동일하게 유지됩니다.

CharliePoole 에 2018년 07월 02일

👍1

FWIW에서 내부를 바라보는 것: 문서화되어 있는 한 자르는 방식은 저에게 정말 중요하지 않습니다.

기본적으로 저는 개발자로서 내부적으로 사용하는 것과 동일한 방식을 사용하는 새 프로젝트를 만났을 때 일반적으로 하는 일을 하려고 노력할 것입니다.

코드 복제
README.md/BUILD.md/HACKING.md 읽기
빌드 시도(변경 사항 없음)
통합 러너를 통해 단위 테스트를 실행합니다.
모든 것이 작동하면 물건을 가지고 놀기 시작하십시오.

과거에는 이것이 ReSharper의 dotCover였을 것이지만 "대부분 작동하는" 무료/오픈 소스 소프트웨어 대안이 있는 경우 라이선스 비용이 소규모 상점/개별 개발자에게 미치기 때문에 우리는 이를 없애려고 노력했습니다.

통합 개발 환경 개념에는 많은 부분이 있습니다. 워크플로에서 튀어나오지 않아도 되므로 매우 유용합니다.

그러나 내 생각에 괜찮은 콘솔 러너(또는 다른 러너)를 사용할 것으로 예상되는 경우 문서화하면 됩니다.

aolszowka 에 2018년 07월 02일

NUnit에서 개발 중이고 프레임워크에서 작업하는 경우 특별한 방식으로 작업을 수행하는 러너(R#, 자체 어댑터)를 혼합하면 문제가 혼동될 수 있다고 생각합니다. 러너로 테스트하기 전에 프레임워크가 격리된 상태에서 올바르게 작동한다는 것을 알고 싶습니다. 그래서 제 작업에서는 nunitlite를 사용하여 CI를 개발하고 로컬에서 실행하면서 테스트합니다. 테스트 탐색기에서 NUnit으로 개발하려는 사람은 여전히 CI를 로컬에서 실행해야 하고 뭔가 이상해 보일 때 nunitlite 또는 nunit3-console로 폴백해야 한다고 말하고 싶습니다.

특정 릴리스에서 nunit 테스트를 실행하는 사람들에게는 훨씬 더 많은 자유도가 있다고 생각합니다.

CharliePoole 에 2018년 07월 02일

모든 프레임워크 테스트에 대해 NUnitLite를 사용하고 종단 간 테스트에 대해 콘솔, VSTest 어댑터 및 UWP 실행기를 사용하여 CI를 정식으로 만들어야 합니다.

CI가 견고하다고 가정하면 Test Explorer, ReSharper, NCrunch 및 CI 스크립트 간에 미묘한 차이가 있어도 괜찮습니다. 이러한 IDE 내 도구를 무시해야 한다고 말하는 것은 내 작업 흐름도 아니기 때문에 기여에 대한 장벽이자 거짓이라고 생각합니다. 나의 이상적인 워크플로우:

기존 테스트 찾기 또는 새 테스트 작성
타이핑하는 동안 테스트를 빠르게 재실행할 수 있도록 테스트 픽스처를 고정합니다(더 나은 방법은 지속적인 테스트 시작).
변경 구현
Git 커밋을 생성하기 전에 .\build.ps1 -t test 를 실행하여 통과 및 실패가 예상대로인지 확인합니다.
놀라움이 있는 경우 내가 알지 못했던 영향을 받는 테스트를 찾아 고정하고 3단계로 이동합니다.

테스트가 러너에 민감한 드문 시나리오에서는 테스트를 러너에 민감하지 않게 만드는 것이 어려운지 잘 모르겠습니다. ReSharper 및 NCrunch 섀도 복사본에 탄력적으로 만든 ILMerge에 대해 작성한 통합 테스트보다 더 나을 수 없습니다.

jnm2 에 2018년 07월 02일

@aolszowka 저는 우리가 무엇을 하든 기여 문서를 사용하기 쉽고 최신 상태로 유지함으로써 기여자의 시간을 존중해야 한다는 귀하의 의견에 100% 동의합니다.

jnm2 에 2018년 07월 02일

@jnm2 나는 당신의 "정식" 접근 방식을 좋아합니다. 테스트 탐색기에서 모든 것이 원활하게 작동하도록 하는 것이 쉬울지 의문이지만 시도해 볼 가치가 있습니다.

nunit에서 작업하는 모든 사람이 언제 더 낮은 수준의 테스트로 전환해야 하는지 아는 것은 여전히 유용하고 필수적입니다.

이 아이디어를 IMO로 발전시키기 위해 우리가 할 수 있는 가장 큰 일은 별도의 시스템과 통합 테스트를 구축하는 것입니다.

CharliePoole 에 2018년 07월 02일

👍1

이것이 근본 원인일 수 있습니다. FrameworkController에서 XML을 가져오는 테스트를 작성하는 동안 TestContext.WorkDirectory 가 C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE 변경되었음을 알았습니다.

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/Api/DefaultTestAssemblyBuilder.cs#L137

호출 스택:

>   nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(System.Reflection.Assembly assembly, string suiteName, System.Collections.Generic.IDictionary<string, object> options) Line 137    C#
    nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> options) Line 114    C#
    nunit.framework.dll!NUnit.Framework.Api.NUnitTestAssemblyRunner.Load(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> settings) Line 154   C#
    nunit.framework.dll!NUnit.Framework.Api.FrameworkController.LoadTests() Line 204    C#

TestContext.WorkDirectory 가 정적 변경 가능 상태이기 때문입니다.

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/TestContext.cs#L96 -L101

즉, 동시 테스트를 포함하여 모든 테스트(!)에서 공유됩니다. WorkDirectory에 의존하는 모든 테스트가 정확하려면 [NonParallelizable] 로 표시되어야 합니다.

jnm2 에 2018년 07월 14일

나는 오래 전에 이 문제를 지적했다. 어딘가에 문제가 있습니다.

NonParallelizable로는 충분하지 않습니다. 많은 NUnit 테스트가 하는 것처럼 테스트가 WorkDirectory를 수정하는 경우 이에 의존하는 다른 테스트가 실패할 가능성이 있습니다.

NUnit에서 정의되지 않은 테스트가 실행되는 순서에 따라 다릅니다.

oznetmaster 에 2018년 07월 14일

의도는 Work 디렉토리가 한 번 설정되고 실행을 위해 변경되지 않은 상태로 유지되어야 한다는 것입니다. 다른 모든 것은 미국 버그입니다.

CharliePoole 에 2018년 07월 14일

각 실행 컨텍스트에 대해 독립적인 작업 디렉터리를 허용할 수 없는 이유가 있습니까?

@CharliePoole 어떻게 그것을 현실로 만들까요? 프레임워크 테스트가 컨트롤러 실행 내에서 실행되는 컨트롤러인 FrameworkController를 테스트하기 때문에 우리는 특별한 위치에 있습니다.

jnm2 에 2018년 07월 14일

테스트를 제외하고 WorkDirectory 의 의미는 "실행을 위한 모든 출력 파일을 수신하도록 사용자가 설정한 디렉토리"입니다. 따라서 테스트는 변경할 수 없어야 합니다.

자체 테스트의 경우 설정할 수 있어야 하지만 올바르게 수행하면 해당 설정이 다른 테스트에 영향을 미치지 않아야 합니다. 우리는 아마도 제대로 하고 있지 않을 것입니다. 😜

핀치에서, 우리는 그것을 변경할 수 없게 만들고 테스트를 중지할 수 있습니다. <ducks>

CharliePoole 에 2018년 07월 14일

그것은 실제로 멋진 아이디어입니다. 정적 필드가 설정되었는지 추적하고 그 후에 설정을 건너뛰나요? 그렇게 하면 변경할 수 없으며 DefaultTestAssemblyBuilder 설정하는지 확인하는 테스트가 표시되지 않으므로 잘해야 합니다!

jnm2 에 2018년 07월 14일

이를 변경하는 NUnit 테스트가 있으며 변경할 수 없게 되면 실패할 수 있습니다.

oznetmaster 에 2018년 07월 14일

@oznetmaster 검색했지만 실수를 제외하고 그것을 변경하는 NUnit 테스트를 찾을 수 없습니다. 핸디가 있나요?

jnm2 에 2018년 07월 14일

내 기록 보관소를 검색해야 합니다.

논의한 내용을 수행하여 이미 CF 빌드의 문제를 수정했습니다. 값을 한 번만 설정할 수 있습니다. null인지 확인하고 null이면 설정하도록 허용합니다.

                if (options.ContainsKey (FrameworkPackageSettings.WorkDirectory))
                    TestContext.DefaultWorkDirectory = options[FrameworkPackageSettings.WorkDirectory] as string;
                else
                    if (TestContext.DefaultWorkDirectory == null)
                        TestContext.DefaultWorkDirectory = Directory.GetCurrentDirectory ();

oznetmaster 에 2018년 07월 14일

문제가 된 테스트는 FrameworkPackageSettings.WorkDirectory가 포함되지 않은 옵션으로 DefaultTestAssemblyBuilder.Build를 호출하여 TestContext.DefaultWorkDirectory를 CurrentDirectory로 덮어쓰게 하는 테스트였습니다. 즉, WorkDirectory가 최상위 실행에서 설정된 경우 테스트에서 덮어쓰여지고 복원되지 않습니다.

oznetmaster 에 2018년 07월 14일

그렇다면 우리도 같은 접근 방식을 취하는 것이 좋을 것 같습니까?

jnm2 에 2018년 07월 14일

나를 위해 작동합니다. 내 CF 빌드는 NUnit 테스트를 100% 통과했습니다.

oznetmaster 에 2018년 07월 14일

👍1

@OmicronPersei 앞으로 며칠 안에 주변에 있다면 @oznetmaster 의 수정 프로그램을 줄 수 있습니까?

jnm2 에 2018년 07월 14일

예! 오늘 저녁에 시도합니다

OmicronPersei 에 2018년 07월 17일

다른 문제를 일으키는 nunit3-vs-adapter#528 때문에 이 버그를 실제로 재현할 수 없습니다. 아이디어?

OmicronPersei 에 2018년 07월 17일

@OmicronPersei 오. 모르겠어요. WorkDirectory 가 올바르게 설정된 .runsettings를 사용하는 것이 좋은 해결 방법입니까?

jnm2 에 2018년 07월 17일

좋아, 나는 그것을 시도했다. TestCaseSourceCanAccessWorkDirectory 는 성공하지만 StackTracesAreFiltered 는 OP에서 동일한 메시지/스택 추적으로 실패합니다.

OmicronPersei 에 2018년 07월 17일

StackTracesAreFiltered를 5로 올려야 한다고 생각합니다. 새 프레임이 추가되는지 확인하기 위한 냄새 테스트이므로 제어를 벗어나지 않았는지 확인할 수 있습니다.

jnm2 에 2018년 07월 17일

TestCaseSourceCanAccessWorkDirectory 는 어떻습니까, 아니면 여전히 이 PR의 범위에 있습니까?

OmicronPersei 에 2018년 07월 18일

ForTestCaseCanAccessWorkDirectory, @oznetmaster 의 수정으로 해결됩니까? 그렇지 않은 경우 추가 조사가 필요합니다.

jnm2 에 2018년 07월 18일

내 컴퓨터에서 문제를 재현할 수 없으며 문제의 테스트는 통과합니다.

OmicronPersei 에 2018년 07월 20일

걱정 마세요. 다른 사람이 그 역할을 할 수 있습니다. 작은 PR도 좋아합니다.

jnm2 에 2018년 07월 20일

집 청소를 하려고 합니다. 이 문제가 여전히 열려 있어야 하는 이유가 있습니까? 아니면 어떤 유형의 해결 방법으로 닫을 수 있습니까? (WONTFIX일지라도).

aolszowka 에 2019년 05월 14일

👍1

아니요, 지적해 주셔서 감사합니다. 폐쇄.

rprouse 에 2019년 05월 14일

👍1

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Nunit: 새 클론 후 nunit.framework.tests에서 실패한 단위 테스트

모든 31 댓글

관련 문제