Nunit: 픽스처 내에서 병렬로 테스트 방법 실행

업데이트: 이 댓글과 다음 댓글은 모두 분명히 자신의 댓글을 삭제한 개인에 대한 답변이었습니다. 답을 남깁니다.

글쎄, 그것은 사양에 있으며 3.0 이후 구현을 위해 예정되어 있습니다. 그게 그렇게 쉬웠다면 우리는 아마 해냈을 것입니다. mbunit과 어떤 연결이 있는지 확실하지 않습니다. 그들이 그것을 가졌다는 사실은 우리에게 도움이 되지 않습니다.

이것은 조금 지루해지고 있습니다. 이미 언급되었지만 분명히 놓친 몇 가지 요점 ...

1. 당신이 요구하는 것을 구현할 계획이 있습니다.
2. 특정 시점에 일정을 잡기로 했습니다.
3. 일정이 언제인지는 주로 다른 기능과 비교하여 해당 기능의 가치를 평가하는 것과 관련이 있습니다.
4. NUnit 팀에는 이 기능을 구현할 수 있는 사람이 여러 명 있습니다.
5. 그들은 우선 순위에 따라 머리 밖으로 그것을 구현할 수 있고 어디에서나 복사할 필요가 없습니다.

"리버스 엔지니어링"에 대한 당신의 이야기는 매우 혼란스럽습니다. 오픈 소스는 저작권이 존중되는 상황에서만 가능합니다. 따라서 mbunit 라이선스 조건을 무시할 수 있다고 제안한다면 기본에서 벗어난 것입니다.

MbUnit에 많은 패치를 제공하고 몇 년 동안 사용했지만
결코 핵심 기여자가 아닙니다. 내 상태가 잘못 표현되는 것을 원하지 않습니다 :)

리버스 엔지니어링의 경우 여기에는 실제로 아무 소용이 없습니다. NUnit 작동
MbUnit과 완전히 다릅니다. 우리는 적절한 시간에 이 문제를 다룰 것입니다.
그러나 다른 유사한 문제가 변경 될 수 있으므로 신중하게 접근하십시오.
우리가 이것을 구현하는 데 필요한 방법 또는 충돌.
2015년 4월 19일 오전 2시 45분에 "CharliePoole" [email protected]이 다음과 같이 썼습니다.

이것은 조금 지루해지고 있습니다. 몇 가지 점은 이미 언급했지만
분명히 놓친...

1.

당신이 요구하는 것을 구현할 계획이 있습니다.
2.

특정 시점에 일정을 잡기로 했습니다.
삼.

예정된 시간은 주로 우리의 평가와 관련이 있습니다.
다른 기능과 비교하여 기능의 가치.
4.

NUnit 팀에는 구현할 수 있는 몇 명의 사람들이 있습니다.
특징.
5.

그들은 우선순위에 따라 그것을 구현할 수 있을 것입니다.
어디에서나 복사할 필요가 없습니다.

"리버스 엔지니어링"에 대한 당신의 이야기는 매우 혼란스럽습니다. 오픈 소스는
저작권이 존중되는 상황에서만 가능합니다. 그래서 만약 당신이
우리가 mbunit 라이선스 조건을 무시할 수 있음을 암시합니다.
베이스.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/nunit/nunit/issues/164#issuecomment -94244650.

나보다 훨씬 재치있는 댓글!

병렬 실행의 세계에서 우리의 현재 우선 순위는 다음과 같습니다.

1. 병렬 프로세스 실행
2. 제외 그룹
3. 병렬 방법(하나의 고정 장치에서) 실행.

이것은 사용자에게 가장 유용한 순서를 나타내는 것 같습니다.

또한 무언가를 3.0 이후로 표시하는 것이 3.0의 일부로 만들 때보다 나중에 해당 기능이 제공된다는 의미는 아니라는 점도 언급하겠습니다. 오히려 3.0이 더 빠른 시점에 온다는 의미일 수 있습니다.

이 작업을 수행할 때 설정 및 해제 명령을 처리하는 방법을 결정해야 합니다. 가장 쉬운 옵션은 데이터에 대한 경합이 없도록 각 테스트에 대한 테스트 클래스를 구성하는 것입니다.

어쨌든 어느 시점에서 옵션을 만드는 것을 선호하지만 실행 옵션인지 고정 장치별(속성) 옵션인지 또는 둘 다인지 확실하지 않습니다.

안녕하세요!
NUnit의 다음 버전에 이 기능을 추가하면 좋을 것입니다. NUnit으로 전환하는 것을 방해하는 유일한 요소이기 때문입니다. 이 기능은 여전히 ​​3.4에 계획되어 있습니까?

@julianhaslinger NUnit 3.4는

참고로, 이 문제는 3.4가 아닌 백로그 이정표(또는 유사 이정표)에 있습니다. 왜냐하면 우리는 미리 번호가 매겨진 각 이정표에 소수의 핵심 정의 문제만 추가하는 관행을 따르고 있기 때문입니다.

다음 이정표인 3.6은 3개월 후에 더 떨어질 예정입니다. :-( 그러나 이 문제가 마스터에 병합되는 것을 본다면 MyGet 피드에서 더 일찍 드롭을 받을 수 있습니다.

@julianhaslinger 이것은 3.4에 포함되지 않을 것이며 이는 아마도 일주일 정도 후에 나올 것입니다.

제쳐두고, 병렬 메서드 실행을 지원하는 어떤 테스트 프레임워크를 사용하고 있습니까? XUnit은 클래스 수준까지 병렬로 테스트를 실행할 수만 있다고 생각했습니다. 내가 틀렸어? 저는 XUnit을 많이 사용하지 않습니다 :스마일:

@CharliePoole 답변 감사합니다! 좋아, 하지만 이것은 약간 낙담하게 들린다. 그러나 다음 릴리스(또는 이전 출시)를 기다릴 것입니다. (여전히) 다음 버전(3.6)에서 이 기능을 고려하십시오.

@rprouse 저는 지금 MbUnit/Gallio를 사용하고 있습니다. 프로젝트가 거의 종료되었고 이제 NUnit으로 전환하겠습니다.

@julianhaslinger 러닝타임의 문제인가요? 픽스처 내 테스트 케이스 분포에 대한 수치가 있습니까? 이 기능이 사용자에게 병렬 고정 장치에서 얻는 것 외에는 거의 제공하지 않는다고 가정했기 때문에 질문합니다. 잘못된 경우 상대적 우선 순위를 변경할 수 있습니다.

@CharliePoole 정확히, 우리의 실제 문제는 테스트 케이스의 실행 시간입니다. 우리는 자동화/회귀 테스트(Selenium/WebDriver 포함)에 NUnit을 사용하고 싶습니다. 일부 테스트 클래스에는 200개 이상의 테스트 케이스가 있기 때문에 현재 NUnit으로 전체 테스트 스위트를 실행하는 것은 정말 힘든 일입니다.

비교(회귀 테스트의 더 작은 테스트 세트 내)는 가능한 NUnit 솔루션이 약 1.5시간 내에 실행되는 반면 현재 MBunit 솔루션은 0.5시간(동일한 테스트 세트)에서 실행되는 것으로 나타났습니다.

그러나 @CharliePoole , 더 큰 테스트 클래스를 더 작은 클래스로 분할하여 실행 시간을 줄일 수 있다는 사실을 알고 있지만, 이는 테스트 클래스 계층 구조의 초기 아이디어를 어떻게든 훼손할 수 있습니다.

@julianhaslinger - 확인하기 위해 실행 시간이 메모리에 종속되지 않고 CPU에 종속된다는 것이 확실합니까?

NUnit 3로 처음 전환을 시도했을 때도 동일한 문제가 발생했습니다. 실행 시간이 상당히 길어졌습니다. 이것은 NUnit이 사용 가능한 메모리를 최대화했기 때문입니다. 그러나 테스트 실행이 완료될 때까지 모든 테스트 개체를 유지하는 현재 버전에 문제가 있습니다. 우리는 현재 내부적으로 패치된 버전을 실행하고 있습니다. 3.4에 대한 PR을 받고 싶었지만 이 시점에서 시간이 있을지 확신이 서지 않습니다. :-(

이것이 아니라면 사과하지만 Selenium이 메모리의 공정한 공유를 사용할 수 있으므로 언급할 가치가 있다고 생각했습니다. :-)

@ChrisMaddock 입력

@ChrisMaddock 3.4에서 메모리 수정을 보고 싶습니다. PR을 올리고 싶다면 아직 제작 준비가 되지 않았다면 정리를 도와드릴 수 있습니다 :+1:

@rprouse - PR #1367의 이 초기 커밋 https://github.com/nunit/nunit/pull/1367/commits/5f98ae51025f7af8244abd4367d1f47260874dfc 는 패치된 v3.0.1에서 우리를 위해 적절하게 해제됩니다.

PR에서 병합하기 전에 OneTimeTearDown 로 이동했음을 알 수 있습니다. 그 이동으로 인해 v3.2.1에서 작동하지 않았는지 또는 다시 도입된 다른 변경 사항이 작동하는지 알 수 없습니다. 보존 - 이사 후 재검사를 하지 않았을 수도 있습니다.

그것을 시도하고 다시 테스트하고 내일 그것을 던질 것이고, 우리가 핵심 릴리스로 돌아가는 것도 좋을 것입니다. :-)

@ChrisMaddock 회귀 테스트 실행 중에 메모리 소비를 살펴보고 테스트 실행 실행이 메모리에 제한되지 않는다는 것을 알았습니다. 각 클래스 내에서 개별 메서드의 병렬 실행을 처리할 수 있는 NUnit 버전을 기다려야 한다고 생각합니다.

@julianhaslinger가 말한 것에 추가하기 위해 Selenium 테스트와 함께 NUnit을 사용할 때 정확히 동일한 문제를 보았습니다. 지금은 병렬 테스트를 실행할 수 있도록 전달된 어셈블리에서 스크랩한 단일 테스트에 대해 nunit-console.exe의 개별 인스턴스를 실행하는 사용자 지정 래퍼를 작성해야 했습니다. 이것은 단일 .xml 출력이 아닌 많은 .xml 출력 파일(각 테스트 실행에 대해 하나씩)이 생성되고 _OneTimeSetUp_ 및 해제 메서드를 사용할 수 없고 대신 외부 세마포어에 의존해야 함을 의미하기 때문에 이상적이지 않습니다. 한 번만 실행하려는 실행 흐름을 제어하는 ​​환경 변수. 나는 오랫동안 NUnit에서 병렬 실행을 한다는 약속을 따랐고 3.0에서 이 기능이 어떻게 출시되었는지에 대해 매우 실망했습니다(부분적으로만 지원되며 문제 및 릴리스 정보에 대한 실질적인 파고가 필요함). 모든 것이 실제로 지원되는 것은 아님을 발견). 나는 이것을 앞으로 나아가는 것과 관련된 것을 조사하기까지했지만 불행히도 NUnit의 디자인이 테스트 방법 수준에서 병렬 실행 구현에 반대하는 것으로 보입니다. 실제로 어떻게 하시겠습니까? 스레드로부터 안전하지 않은 코드의 가능성을 처리하기 위해 여전히 일회성 설정 및 분해 유형 방법을 한 번만 실행하려고 함) 이미 해결 방법이 있으므로 이 기능을 직접 구현하는 시간을 정당화할 수 없습니다. GitHub에서 팀과 협력하여 병렬 실행을 구현하도록 지원). 어쨌든... 어지럽게 해서 죄송합니다... C# 코드의 단위 테스트에 대한 우선 순위가 메서드 수준 병렬 처리에 그다지 의존하지 않는다는 것을 이해하지만 Selenium 기반 테스트에 NUnit을 사용하는 사람들을 위해 알아두십시오. 그것은 엄청난 개선이 될 것입니다. 미리 감사드립니다! :웃다:

귀하의 의견에 감사드립니다. 여기서 좀 헤매게 될 것 같아요...

사람들에게 무엇이 필요한지, 왜 필요한지 이해하는 데 도움이 됩니다. 저는 웹 개발자가 아니라 Selenium 사용자의 말을 경청하고 그들이 원하는 것에 집중하려고 노력했습니다. 테스트 케이스 사이에 순서가 있는 병렬 고정 장치인 것 같았습니다. 나는 다른 사람들이 다른 것을 원할 것이라는 것을 충분히 이해하지만 두 그룹이 "Selenium 사용자가 필요로하는 것"을 표현하는 것으로 표현하면 약간 혼란 스럽습니다. 미리 정의된 순서로 메서드를 실행하려는 사람들과 달리 어떤 종류의 웹 테스트가 메서드 수준 병렬 처리를 원할 수 있는지 간략하게 설명할 수 있습니까? 추측할 수는 있지만 사용자로부터 받는 것이 좋습니다.

해결 방법과 관련하여... 별도의 테스트 어셈블리 사용을 고려했습니까? NUnit은 개별 프로세스에서 각각을 병렬로 실행하게 되어 기쁩니다. 물론 그렇다고 해서 파일과 같은 것에 대한 액세스를 동기화할 필요가 없는 것은 아닙니다.

스레드 안전과 관련하여 - 우리는 병렬 구현이 스레드 안전에 대한 책임을 지도록 계획하지 않았습니다. 내가 보증을 기다리고 있었다있는 유일한 방법은 당신의 방법은 이미 스레드 안전한지 NUnit과 어떤 스레드 안전 문제를 만들 것입니다. 그것은 그 자체로 사소하지 않은 것으로 밝혀졌습니다.

응답해 주셔서 감사합니다. 에 대한 귀하의 의견을 완전히 이해합니다.
픽스처에서 테스트 실행 순서 지정 및 테스트를 개별적으로 분할
어셈블리.

저는 이미 NUnit 사용자이며 몇 년 동안(그리고 그 전에는 JUnit도 사용했습니다)
그래서 픽스처에서 테스트 순서에 의존한다는 아이디어는 심지어
내 테스트 디자인에서 고려하십시오. 각 테스트는 완전히 캡슐화됩니다.
순서에 대한 기대 없이 사이트 내에서 작업 또는 일련의 작업
실행. 내가 테스트하는 사이트의 디자인은 또한 많은 테스트가
실행하는 데 최대 20분이 소요될 수 있습니다(이 시간의 대부분은
사이트에서 발생하는 일) 및 테스트 유형이 포함됩니다.
코드를 줄이기 위해 기본 테스트 클래스가 활용되도록 여러 유사한 시나리오
공통 기본 클래스를 사용하여 복제 및 유지 관리 용이성 향상
행동 양식. 테스트는 개발자를 기반으로 별도의 프로젝트로 구성됩니다.
해당 영역의 팀 소유권(따라서 별도의 어셈블리를 사용하지만
어셈블리당 많은 테스트가 있으며 내 테스트 래퍼가
이전에 생성된 대로 병렬로 어셈블리에서 통과된 모든 테스트
NUnit 3의 첫 번째 공식 릴리스이며 모든 테스트가
충분한 스레드가 주어지면 동시에 실행될 가능성
사용 가능).

기본적으로 하나의 어셈블리에 10개의 테스트가 있고
또 다른 100개의 테스트를 수행하지만 10개가 있는 어셈블리에는 10분이 소요되는 테스트가 있습니다.
각각 100개가 포함된 어셈블리에는 각각 1분이 소요되는 테스트가 있습니다. 만약 내가
110개의 병렬 스레드(실제로는
인프라 설계의 일부) 그러면 테스트가 완료될 것으로 예상됩니다.
100분이 아니라 10분 안에.

이것이 설명에 도움이 되기를 바랍니다... 상황이 여전히 완전히 명확하지 않은 경우 죄송합니다.
하지만 전반적인 요점은 메서드 수준 병렬 처리가
다른 테스트 라이브러리(예: ruby의 prspec)에서 누락된 경우
나는 그것을 추가함으로써 가질 성능 개선의 분석을 수행
중요한 긍정적인 변화가 될 수 있음을 발견했습니다. 예를 들어 다음을 참조하십시오.
https://github.com/bicarbon8/rspec-parallel/wiki/Examples
2016년 7월 1일 00시 45분에 "CharliePoole" [email protected]이 다음과 같이 썼습니다.

귀하의 의견에 감사드립니다. 여기서 좀 헤매게 될 것 같아요...

사람들에게 무엇이 필요한지, 왜 필요한지 이해하는 데 도움이 됩니다. 아닌 것
웹 개발자 본인도 Selenium 사용자의 말을 듣고 무엇에 집중하려고 했는지
그들은 원했다. 주문과 병행하는 것 같았던 것은
테스트 케이스 중에서. 나는 다른 사람들이 원하는 것을 충분히 이해합니다.
그러나 두 그룹이 자신을 표현하는 것으로 제시할 때
"셀레늄 사용자가 필요로 하는 것"은 약간 혼란스럽습니다. 당신은 나를 위해 개요를 할 수 있습니다
어떤 종류의 웹 테스트가 메소드 수준 병렬 처리를 원할 수 있습니까?
미리 정의된 순서로 메서드를 실행하려는 사람들? 나는 내가 할 수 있다고 생각한다
추측하지만 나는 사용자로부터 그것을 받고 싶습니다.

해결 방법과 관련하여 ... 별도의 테스트 사용을 고려 했습니까?
어셈블리? NUnit은 각각을 별도의 병렬로 실행하게 되어 기쁩니다.
프로세스. 물론 액세스를 동기화할 필요가 없는 것은 아닙니다.
파일 같은 것들.

스레드 안전성 관련 - 우리는 병렬 구현을 계획한 적이 없습니다.
스레드 안전성에 대한 책임을 집니다. 내가 기대했던 유일한 것은
보장은 다음과 같은 경우 NUnit이 스레드 안전 문제를 _생성하지 않는다는 것입니다.
메소드는 이미 스레드로부터 안전합니다. 그것은 그 자체로 사소하지 않은 것으로 밝혀졌습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/nunit/nunit/issues/164#issuecomment -229819324 또는 음소거
스레드
https://github.com/notifications/unsubscribe/ACNsyoczCUV9L7kbF2SHB7lLsyBKlrv9ks5qRFUJgaJpZM4CUZ8r
.

정보 감사합니다... 다양한 관점을 볼 수 있어서 도움이 됩니다.

내 5센트.

우리 프로젝트에는 ~25개의 테스트 어셈블리와 어셈블리 및 고정 장치당 테스트의 병렬 테스트 실행이 이미 실행 시간을 크게 줄였습니다. 픽스처 내에서 테스트를 병렬로 실행하면 훨씬 더 향상됩니다. 이제 우리는 실행 속도를 높이기 위해 대부분의 시간이 소요되는 고정 장치를 여러 개의 고정 장치로 분할합니다. 그러나 nunit이 고정 장치 테스트를 병렬로 실행하면 훨씬 더 좋을 것입니다.

nunit에서 내가 정말로 보고 싶은 것은 테스트 케이스 수준의 테스트 병렬화입니다. 왜냐하면 그러한 테스트를 고정 장치로 분할하는 것이 항상 편리하지 않고 코드 중복으로 이어지기 때문입니다. 우리는 최대 수천 개의 테스트 케이스(각 케이스 실행은 빠르지만 총 몇 분이 소요됨) 또는 수십 개의 케이스(각 케이스는 느림)를 수행할 수 있는 여러 테스트를 가지고 있으며 현재로서는 이러한 테스트가 주요 쇼 스토퍼입니다. 우리를.

입력해 주셔서 감사합니다... 이 부분은 일부 테스트가 서로 병렬로 실행되지 않도록 하는 경쟁적이지만 보완적인 문제와 함께 다음 릴리스에서 다루게 될 영역입니다!

내 이전 질문은 특히 웹 애플리케이션을 구동할 때 사람들이 테스트를 작성하는 방법에 관한 것이었습니다. 어떤 사람들은 각 방법이 순서화된 단계를 원하고 고정 장치가 일련의 그러한 단계를 나타내기를 원한다고 주장합니다. 이것은 물론 정의상 평행하지 않습니다. 다른 사람들은 테스트 순서를 지정하지 않고 매우 유사한 테스트를 작성하는 것으로 보입니다. 내 생각에 후자 그룹은 일련의 작업과 각각의 주장을 포함하는 더 큰 테스트 방법을 작성합니다.

@CharliePoole 좋은 소식입니다! 정말 고맙습니다!

내 생각에 테스트 케이스는 격리되어야 하고 다른 테스트 케이스나 실행 순서에 의존하지 않아야 합니다. 사람들이 여전히 단일 스레드로 일부 테스트를 실행하려는 경우 [Parallelizable(ParallelScope.None)] 및/또는 OrderAttribute를 사용할 수 있습니다.

구현 중인 이 문제를 통해 로컬 웹드라이버 그리드 또는 BrowserStack 또는 SauceLabs와 같은 Saas 공급자에 비해 테스트 스위트를 더 빠르게 실행할 수 있습니다. 현재 저는 테스트 클래스의 테스트 메소드의 양을 사용 가능한 웹 드라이버 노드 또는 브라우저 세션의 수로 제한하려고 시도하므로 그리드가 완전히 사용됩니다. 그렇지 않고 테스트에 8개의 테스트 메서드가 있고 내 그리드에 사용 가능한 8개의 브라우저 세션이 있는 경우 클래스의 모든 테스트 메서드가 한 번에 하나씩 실행되기 때문에 하나만 사용됩니다.

@pablomxnl 전적으로 동의합니다. 코치 또는 프로젝트 리더로서 저는 항상 그 아이디어를 매우 열심히 추진해 왔습니다. 그러나 나는 여기에서 그 모자를 쓰지 않습니다. 나는 무언가를 요구하는 사용자와 소프트웨어 제공자입니다. 그들이 정말로 지독한 것을 요구한다면, 나는 그냥 아니라고 대답합니다. 그러나 그들이 어떤 상황에서는 합리적인 것을 요구하지만 다른 상황에서는 그렇지 않은 경우(대부분이 아닌 경우에도) 고려합니다.

웹 사이트의 경우 거의 항상 단위 테스트에 대해 이야기 하지 않습니다 . 더 높은 수준의 기능 테스트에는 종종 시퀀싱이 필요합니다. 테스트의 일련의 단계를 통해 수행되는지 일련의 방법을 통해 수행되는지 여부는 우리에게는 구현 세부 사항이고 사용자에게는 편의 문제입니다. 개인적으로, 우리는 아마도 [StepFixture] 클래스 안에 있는 [Step]이라는 것이 필요하거나 이와 유사한 이름이 필요할 것이라고 생각합니다. 그래야 이 모든 순서/시퀀싱 항목을 단위 테스트에서 제거할 수 있습니다. 아마도 웹이 죽기 전에 그렇게 할 시간이 있을 것입니다. :-)

어쨌든 사람들이 여러분의 소프트웨어를 실제로 어떻게 사용하는지 배우는 것은 항상 흥미롭습니다.

@CharliePoole , 다음과 같이 질문하여 저를 오해하지 마십시오. 이 기능이 다음 버전(3.5, 2016년 9월 29일까지)에 추가되나요?

내가 미래를 예측하는 척 할 수는 있지만, 그것은 9월까지만 당신을 만족시킬 것입니다. :-)

기능을 "예약"하는 방법을 설명하여 답변하겠습니다.

우리는 현재 분기에 한 번 릴리스가 나오는 접근 방식을 (연초부터) 시도하고 있습니다. 출시를 더 잘하게 되면 속도를 높일 수 있습니다. 결국 지속적으로 배포할 수 있습니다.

자원 봉사 오픈 소스 프로젝트에서 매월 사용할 수 있는 고정된 양의 노력은 없습니다. "어제 날씨" 접근 방식을 사용할 수 있지만 사람들이 NUnit에 소비해야 하는 시간과 자원 봉사 인원 수는 매우 다양합니다.

타협으로 우리는 릴리스의 핵심이 되는 소수의 문제를 선택하여 미리 이정표에 추가합니다. 내가 선호하는 것은 완료되기를 바라는 것의 약 25% 이상을 추가하지 않는 것입니다. 릴리스의 대부분의 문제는 작업이 완료된 후 또는 기껏해야 누군가가 작업에 전념할 때만 해당 이정표에 추가됩니다. 누군가가 할당되지 않은 상태에서는 일반적으로 3.5 마일스톤에서 미해결 문제를 찾지 못할 것입니다. 하지만 무언가 다른 작업을 방해하는 것처럼 보이는 경우 가끔 확인합니다.

따라서 우리가 하는 일의 긍정적인 측면은 릴리스가 제시간에 나올 것이라고 사실상 보장할 수 있다는 것입니다. 부정적인 측면은 그 안에 무엇이 들어 있는지 말할 수 없다는 것입니다. :-(

이 특정 문제에 대해... 저는 우리 개발자들에게 이것이 중요하다는 것을 알리기 위해 높은 우선 순위를 부여했습니다. 누군가는 자유롭게 작업할 수 있어야 하며 이 범위와 어려움의 프로젝트에 대한 충분한 배경 ​​지식이 있어야 합니다. 올바른 배경을 가진 누군가가 앞으로 몇 주 안에 이것을 선택한다면, 나는 그것이 릴리스까지 완료될 수 있다고 추측할 것입니다. 참고로 저는 다른 일을 하면서 이 일을 하는 데 한 달 정도 걸릴 것 같아요.

죄송하지만 더 이상 확실한 답변은 없지만 그러한 답변은 반드시 거짓말이 될 것입니다!

@CharliePoole 이 기능을 고려한 업데이트가 있습니까?

@tomersss 우리는 아직 이것에 대한 작업을 시작하지 않았으며 3.5가 몇 주 안에 나오기를 희망하므로 다음 릴리스에는 없을 것입니다. 이 기능이 곧 추가되는 것을 보고 싶지만 이번 주에 리포지토리와 코드 기반을 재구성하느라 꽤 바빴습니다. 그러나 높은 우선 순위로 표시되어 있으므로 레이더에 있습니다.

@CharliePoole 이 문제에 대한 업데이트가 있습니까?

@KPKA 아직 작업을 시작하지 않았으므로 업데이트가 없습니다. ZenHub가 설치된 사용자의 경우 이 문제가 작업을 시작하면서 Backlog에서 ToDo로 이동한 다음 In Progress로 이동하는 것을 볼 수 있습니다.

Zenhub를 사용하지 않는 사용자의 경우 문제에 할당된 사람을 보면 누가 그것을 선택했는지 알 수 있습니다.

@CharliePoole @rprouse

안녕하세요!

이 문제에 따른 소식이 있습니까?
다음 릴리스에 포함될 것인지 아니면 다가오는 이정표 중 하나에서 계획될 것인지?

현재 이것이 NUnit으로 전환하는 것을 방해하는 유일한 문제입니다.
많은 사람들이 영향을 받았기 때문에 가까운 시일 내에 누군가가 자신을 고백하여 이 일에 착수할 수 있다면 친절할 것입니다.

곧 소식을 들을 수 있기를 바랍니다.

@GitSIPA 테스트 방법을 병렬로 실행할 수 있도록 어떤 테스트 프레임워크를 사용하고 있습니까?

귀하의 질문에 답하기 위해 아무도 이 문제에 대해 작업을 시작하지 않았으므로 ETA는 없지만 다음에 작업할 작업을 결정할 때 귀하의 투표를 고려할 것입니다.

+1, @GitSIPA에 동의합니다. 정말 중요한 기능입니다

@GitSIPA +1
@rprouse 우리는 mbunit을 사용하고 있지만 이 프레임워크는 지금 지원하지 않습니다. mbunit에 몇 가지 문제가 있습니다.

@rprouse 저희도 현재 MbUnit을 사용하고 있지만 새로운 Visual Studio 버전은 지원하지 않기 때문에 NUnit으로의 전환을 고려했습니다.

문제 #1921에서 @jnm2 는 "우리와 매개변수화된 테스트 케이스를 병렬로 실행하는 것 사이에 어떤 차이가 있습니까? 제가 기여할 수 있습니까?"라고 물었습니다.

두 번째 질문 첫 번째: 확실히! 우리는 당신의 도움을 받고 싶습니다.

그리고 첫 번째 질문에:

1. 우리는 현재 일대일 테스트를 매핑하는 "WorkItems"를 실행합니다. 고정 장치에 대한 OneTimeSetUp 및 OneTimeTearDown을 예비 단계로 별도의 WorkItem으로 처리해야 한다고 생각합니다. 문제 #1096은 이에 대해 다룹니다.

2. WorkItem이 다른 WorkItem에 종속되도록 하는 방법이 필요하므로 종속된 항목이 모두 완료될 때만 실행되도록 예약됩니다. 우리는 현재 CountDown을 사용하여 매우 단순한 방식으로 이를 수행하지만 보다 일반적인 것이 필요합니다. 물론 이것의 첫 번째 사용은 OneTimeTearDown이 모든 테스트의 완료에 의존하도록 하는 것입니다. 나중에 테스트 간의 종속성을 구현할 때 다른 용도로 사용할 수 있습니다. 나는 이것을 보류 중인 작업 항목의 대기열로 생각하지만 다른 방법으로 구현할 수도 있습니다.

3. 이 두 가지를 제외하고 주요 문제 자체에 대한 작업을 시작할 수 있습니다. 즉, 고정 장치에 대해 OneTimeSetUp을 수행한 동일한 스레드에서 테스트를 실행하는 대신 실행하도록 테스트를 예약하는 것입니다.

이 작업을 수행하려면 NUnit이 실제로 실행을 위해 테스트를 전달하는 방법에 대한 내부 사항에 매우 익숙해져야 합니다. 기꺼이 도와드리겠습니다.

지금까지 어떤 계획이 있었나요?
내 요구 사항은 CPU를 포화시키기 위해 병렬로 충분한 TestCaseSource 케이스를 실행하는 것입니다. 설정, 분해 또는 주문 요구 사항이 없습니다. 다른 사람들은 그것들을 고려해야 할 것입니다.

TestCaseSource 실행이 병렬화될 것으로 예상하므로 다른 TestCaseSources를 사용하는 동일한 고정 장치의 두 메서드가 열거를 병렬로 실행합니다. 또한 한 번만 실행된다면 두 개의 메소드가 동일한 TestCaseSource를 사용한다면 좋을 것 같습니다.

편집: RACE CONDITION에 댓글을 달고 있습니다. 우리는 이미 좋은 출발을 하고 있습니다! 😆

내가 최근에 많이 해야만 했던 이야기를 반복할 것이다. :웃다:

NUnit은 먼저 테스트(발견, 탐색)를 로드한 다음 러너 유형에 따라 테스트를 한 번 이상 실행합니다.

TestCaseSource는 테스트를 실행하는 것이 아니라 로드하는 데 사용되며 테스트와 동일한 클래스에 있을 수 있지만 테스트의 일부로 간주하지도 않습니다.

IOW, 테스트 케이스는 테스트 케이스 소스를 "사용"하지 않고 NUnit이 소스를 사용하여 테스트 케이스를 생성합니다. 물론 생성될 때까지는 아무 것도 할 수 없습니다. 말이 됩니까?

그런 일이 발생하면 소스에서 테스트 생성이 순차적으로 수행됩니다. 문제가 되는 소스에서 실행 중인 코드가 있는 경우 첫 번째 추측은 테스트 케이스 소스에서 너무 많은 작업을 수행하고 있다는 것입니다. 예를 들어 테스트 케이스 소스에 클래스의 인스턴스를 생성하는 것이 아니라 생성하는 데 사용할 매개변수를 저장하려고 합니다. 불행히도 이것은 전체 책 챕터가 될 수 있습니다. :웃다:

따라서 이 문제는 테스트 케이스를 병렬로 __running__하는 것입니다. 이는 일부를 병렬화할 수 없는 것으로 표시하지 않는 한 고정 장치 아래의 모든 테스트 케이스를 의미합니다. 단순하고 매개변수화되지 않은 테스트와 매개변수화된 테스트의 개별 사례는 여기에서 동등하게 취급됩니다.

OneTimeTearDown이 없는 설비에서 테스트의 병렬화를 허용하는 것은 흥미로운 실험이 될 것입니다(OneTimeSetUp이 괜찮다고 생각합니다). 그 결정을 올바르게 내릴 수 있다면 쉽게 작동할 수 있습니다. 그러나 OneTimeTearDown은 상속된 메서드와 전역 ActionAttributes를 모두 포함할 수 있기 때문에 결정이 생각보다 어렵습니다.

@jnm2 이미 이 특정 문제를 해결할 기회가

@julianhaslinger 아니요. 1885년과 1933년의 두 가지 즉각적인 문제 이후에 내 목록에 있습니다. 문제를 해결하고 싶다면 더욱 좋습니다!

@julianhaslinger 서로에 대해 잘 감당 하기 힘든 일이라고 말씀 https://github.com/nunit/nunit/issues/164#issuecomment -265267804에서 내 의견을 참조하십시오. 더 간단한 접근 방식이 생각나면 코딩하기 전에 이에 대해 게시하면 미래 예측과 관련된 명백한 YAGNI와 미래 고려 사항을 비교할 수 있습니다.

@CharliePoole @jnm2 안녕하세요 여러분!

이 누락된 기능의 구현을 시작하려는 것이 아니라 단지 진행 상황에 대해 알고 싶었습니다. 귀하의 답변(위)에서 알 수 있듯이 이 특정 기능 요청과 관련하여 진행(?)이 없었습니다.

@CharliePoole 코드를 조사하는 동안 동일한 Fixture 인스턴스에 액세스할 수 있습니다. 즉, WorkItem이 병렬로 실행되는 경우 테스트 클래스의 단일 인스턴스에 액세스하게 됩니다. 이는 테스트가 인스턴스 수준 필드를 설정하기 위해 설정 또는 해체에 의존할 때 생성되는 경쟁 조건 때문에 문제가 됩니다.

이에 대한 한 가지 해결책은 각 WorkItem이 테스트 클래스의 새 인스턴스에서 작동하도록 하는 것이지만, 이는 더 이상 고정 장치의 단일 인스턴스가 없기 때문에 고정 장치 설정이 작동하는 방식을 복잡하게 만듭니다

@chris-smith-zocdoc 네, 그게 NUnit과 전임자 junit의 가장 큰 차이점입니다. 과거에는 찬반 양론이 널리 논의되었지만 지금은 많이 나오지 않습니다. 이러한 이유로 NUnit 테스트는 모든 초기화가 SetUp 메서드에서 수행되는 상태 비저장으로 가정되었습니다.

TestFixtureSetUp(현재 OneTimeSetUp이라고 함)이 도입되면 더 비싼 초기화를 한 번 수행하고 모든 테스트가 동일한 초기화 값에서 작동하도록 할 수 있게 되었습니다. 이것은 테스트 중인 클래스의 인스턴스를 생성할 때 가장 유용하며, 그 자체가 상태 저장일 수 있습니다. 최근 몇 년 동안 점점 더 많은 사용자가 이 기능을 활용하고 있습니다.

테스트 케이스별로 별도의 사용자 픽스처 인스턴스를 생성하는 옵션을 추가하는 주제가 주기적으로 올라옵니다. 아직까지 예정된 기능의 단계에 이르지 못했습니다. 확실히 사용자 측의 병렬 방식 기능의 유용성과 관련이 있지만 구현과 직교한다고 생각합니다. 인스턴스당 새 조명기를 생성하는 경우 단순히 "일회성" 설정을 두 번 이상 실행할 것입니다. 물론 정적을 사용하는 모든 사용자에게 큰 타격을 줄 것입니다. 😢

우리는 두 가지 이유로 병렬 테스트 방법을 연기했습니다. (1) 구현하기 어렵고 (2) 병렬 고정 장치가 우리에게는 더 쉽지만 대부분의 사용자에게는 충분합니다. 매우 소수의 사용자가 여러 고정 장치에서 상태를 공유하는 것처럼 보이지만(온라인 토론을 기반으로) 많은 사용자가 여러 테스트 방법에서 상태를 공유합니다. 지금까지 많은 사용자가 병렬 처리를 활용하고 있으며 일부 사용자는 메서드 병렬 처리를 매우 심하게 원하지만 상대적으로 작은 그룹인 것 같습니다.

그럼에도 불구하고 뭔가를 해야 할 때라고 생각합니다. 나는 첫 번째 분기 동안 이 작업을 수행할 것입니다. 최소한 몇 가지 실험을 실행하고 다른 사람들이 후속 조치를 취할 수 있는 작업을 합리적으로 분류할 수 있을 정도로 말입니다.

인스턴스당 새 조명기를 생성하는 경우 단순히 "일회성" 설정을 두 번 이상 실행할 것입니다. 물론 정적을 사용하는 모든 사용자에게 큰 타격을 줄 것입니다.

나는 당신이 병렬로 실행하기로 선택했다면 정적 상태와 병렬 처리를 혼합하여 무언가가 망가지면 당신의 잘못이 될 정도로 정적 상태가 없도록 요구하는 것이 합리적이라고 생각합니다. 운 좋게도 모든 코드가 테스트 중이므로 놓치기 어려울 것입니다 😆

그럼에도 불구하고 뭔가를 해야 할 때라고 생각합니다. 나는 첫 번째 분기 동안 이 작업을 수행할 것입니다. 최소한 몇 가지 실험을 실행하고 다른 사람들이 후속 조치를 취할 수 있는 작업을 합리적으로 분류할 수 있을 정도로 말입니다.

저를 계산해 주세요.

나도!

2017년 1월 14일 토요일 오전 3시 58분, Joseph Musser [email protected]
썼다:

>
>
>
>

[이미지: 박스비] https://www.boxbe.com/overview

자동 정리: 마지막 1개 이메일 보관([email protected])

규칙 수정
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D&tc_serial=28420100882&tc_rand=1283ut39648

| 규칙 삭제
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D&tc_serial=28420100882&tc_rand=1283ut39648

| 중요 표시
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ % 252BtolspNKBzqBxtH6H 252FhqnTQ % % % 253D 253D 26important % % % 3Dtrue 26emlId % 3D54854949581 및 tc_serial = 28,420,100,882 및 tc_rand = 128,339,648 = & utm_source를 STF 및 이메일에 utm_medium = & utm_campaign을 ANNO_CLEANUP_EDIT = & 한 utm_content = 001

인스턴스당 새 조명기를 생성하는 경우 단순히 "하나"를 실행합니다.
시간 설정을 두 번 이상 합니다. 물론 이는
정적을 사용합니다.

다음과 같은 경우 정적 상태가 없도록 요구하는 것이 합리적이라고 생각합니다.
병렬 실행을 선택하십시오.
정적 상태와 병렬 처리를 혼합하기 위한 중단. 운 좋게도 이 모든 코드는
테스트 중이니 놓치지 마세요 :D

그럼에도 불구하고 뭔가를 해야 할 때라고 생각합니다. 나는 이것을 맡을 것이다.
1분기에는 최소한 일부 실험을 실행하는 정도까지
다른 사람들이 할 수 있는 작업을 합리적으로 분류할 수 있습니다.
후속 조치를 취하십시오.

저를 계산해 주세요.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/nunit/nunit/issues/164#issuecomment-272488655 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAHNVlwVps8pQ93UIwZw6zY7TOyHO0a6ks5rR61EgaJpZM4CUZ8r
.

몇 가지 타이밍 테스트를 실행하면서 흥미로운 것을 발견했습니다. 병렬화 가능한 테스트 케이스를 호출하는 데 모호함이 있습니다. 이것은 비품 및 기타 제품군에도 적용될 수 있지만 덜 명확합니다.

방법이 완전히 병렬화할 수 없는 경우 __다른 방법__과 병렬로 실행할 수 없음을 의미합니다. OTOH, 픽스쳐 내에서만 병렬화할 수 없는 경우 __동일한 픽스처의 다른 메서드와 병렬로 실행할 수 없습니다.__

저는 이 구분을 다음과 같이 처리할 것을 제안합니다.

1. 테스트 메서드에 Parallelizable 속성이 없는 경우 다른 속성(예: 아파트)에서 다른 스레드에서 실행되도록 호출하지 않는 한 포함하는 고정 장치와 동일한 스레드에서 실행해야 합니다.

2. 범위가 Self인 Parallelizable 속성이 있거나 더 높은 수준의 제품군이 Children의 범위를 지정하는 경우 테스트 메서드는 조명기의 다른 메서드와 병렬로 실행됩니다.

생각 @nunit/core-team ?

위에서 제외:

1. 범위가 None인 Parallelizable 속성이 있으면 병렬이 아닌 큐에서 실행됩니다.

@CharliePoole - 귀하의 3가지 포인트는 이해가 되지만, 귀하가 제안하는 대안이 무엇인지 명확하지 않습니다. 명확히 해주시겠습니까?

현재 특성이 없는 것은 ParallelScope.None이 있는 것과 동일하게 취급합니다. 디스패치를 ​​활성화하고 테스트 실행이 크게 느려지면 병렬이 아닌 대기열에 대기열에 추가됩니다.

PR #2011은 이 기능을 구현하기 위한 몇 가지 초기 단계를 수행하지만 테스트 케이스가 포함된 고정 장치의 스레드에서 실행되도록 강제하는 #define이 포함되어 있습니다. 이 의견은 그 제한을 제거하기 위해 수행해야 한다고 생각하는 것을 문서화합니다.

현재 픽스처의 OneTimeTearDown은 실행된 마지막 테스트 케이스를 완료하는 데 사용된 스레드에서 실행됩니다. 테스트 케이스가 병렬로 실행되면 어떤 테스트 케이스가 될지 예측할 수 없습니다. Fixture에 필요한 것과 다른 특성을 가진 스레드일 수 있습니다. 예를 들어 마지막으로 완료할 테스트가 STA에서 실행 중인 경우 OneTimeSetUp이 MTA에서 실행된 경우에도 이 테스트가 OneTimeTearDown을 실행하는 데 사용됩니다. 대부분의 경우 문제가 발생하지 않을 수 있지만 일부에서는 문제가 발생할 수 있습니다.

이것은 실제로 더 높은 수준의 픽스처에서도 문제가 될 수 있지만 병렬 테스트 케이스의 도입은 오류를 유발하는 불일치에 대한 더 많은 기회가 있음을 의미합니다.

따라서 고정 장치 분해가 올바른 종류의 스레드에서 발생하도록 하기 위해 마지막으로 실행할 테스트의 스레드에서 더 이상 실행할 수 없습니다. 대신, 디스패처는 보류 중인 모든 분해에 대한 정보를 유지 관리해야 하며 적절한 시간에 적절한 스레드에서 해당 분해를 실행하라는 알림을 받아야 합니다. 이를 수행하는 방법을 파악하는 것이 이 기능의 "설계" 단계입니다.

2014년 초부터 이 스레드를 팔로우하고 있고 이 기능 추가를 기다리는 동안 자체 해결 방법을 구현하고 싶지 않거나 구현할 수 없는 사람을 위해 NUnit 2.6.3을 사용할 수 있는 구현을 우연히 발견했습니다. 사용하기 매우 간단해 보이는 CodePlex(여러 병렬 스레드에서 기능 테스트를 실행할 때 작동함을 확인했습니다).

http://cpntr.codeplex.com/

이 메시지가 이 스레드에 대한 최근 토론과 약간 직교하는 경우 사전에 @CharliePoole 사과하지만 다른 누군가가 NUnit 3에 대해 약속된 약속을 기반으로 지난 3년 동안 이 기능 추가를 기다렸다면(초기에 일), 여러분이 디자인 문제를 해결할 때까지 솔루션을 제공할 수 있다고 생각합니다(솔루션에 접근하는 것처럼 들림).

@찰리풀

따라서 고정 장치 분해가 올바른 종류의 스레드에서 발생하도록 하기 위해 마지막으로 실행할 테스트의 스레드에서 더 이상 실행할 수 없습니다. 대신, 디스패처는 보류 중인 모든 분해에 대한 정보를 유지 관리해야 하며 적절한 시간에 적절한 스레드에서 해당 분해를 실행하라는 알림을 받아야 합니다. 이를 수행하는 방법을 파악하는 것이 이 기능의 "설계" 단계입니다.

디스패처가 보류 중인 분해 항목을 미리 알아야 합니까, 아니면 사용할 수 있게 되면 디스패치할 수 있습니까? 더 구체적으로, CompositeWorkItem이 현재 PerformOneTimeTearDown 을 호출하는 위치에서 디스패처를 사용하여 새 작업 단위를 올바른 작업 교대에 파견할 수 있습니까?

@chris-smith-zocdoc 네, 그게 바로 제가 하는 일입니다. CompositeWorkItem 중첩되어 있고 마지막 자식 테스트가 실행될 때 전달되는 새로운 유형의 작업 항목 OneTimeTearDownWorkItem 을 만들었습니다. 나중에 OneTimeSetUp과 모든 테스트가 동일한 스레드에서 실행되었을 때 몇 가지 효율성을 살펴볼 수 있습니다.

모든 것을 너무 주의 깊게 읽지는 않았지만 이 기능의 일부로 요청하고 싶은 한 가지는 병렬 처리가 특히 I/O 바운드 테스트의 경우 "스마트"해야 한다는 것입니다. 예를 들어, 100개의 병렬화 가능한 테스트를 실행하는 10개의 스레드가 있는 경우 10개의 스레드가 앉아서 다음 10개의 테스트로 이동하기 전에 처음 10개의 테스트가 완료될 때까지 기다리는 경우가 되어서는 안 됩니다. 처음 10개의 테스트가 매우 오래 실행되는 I/O 작업을 기다리기 시작하면 스레드는 다른 테스트로 자유롭게 이동할 수 있어야 합니다. I/O 작업이 완료되면 스레드가 해제되면 스레드가 대기 중인 테스트를 재개합니다.

기본적으로 async/await를 광범위하게 사용하는 I/O 바운드 테스트를 위한 스마트 처리량 관리를 요청합니다. 이것은 지금까지 테스트에서 가장 큰 병목 현상입니다.

@chris-smith-zocdoc 사실, 그게 제가 하고 있는 일입니다. 저는 기본적으로 기존 카운트다운 메커니즘을 사용하여 일회성 분해 작업의 디스패치를 ​​트리거합니다. 비결은 적절한 대기열에 전달되도록 하는 것입니다.

@gzak 병렬 실행을 위한 메커니즘이 이미 존재한다는 점을 염두에 두십시오. 작업자에게 작업을 푸시하는 컨트롤러가 아니라 작업자가 독립적으로 작업을 가져오는 데 의존합니다. 따라서 한 작업자가 한동안 작업으로 바쁘면 다른 작업자가 계속 다른 작업을 독립적으로 실행합니다. 비결은 실행 중인 테스트의 특성에 따라 작업자 수를 설정하는 것입니다. NUnit은 기본적으로 일반 컴퓨팅 바운드 단위 테스트에서 상당히 잘 수행되지만 다른 종류의 테스트에서는 사용자가 적절한 수준의 병렬 처리를 설정해야 할 수 있습니다.

누군가가 어떻게 작동하는지 설명할 수 있습니까?
시험 수업이 있어요
병렬이 아닌 이 클래스에서 테스트를 실행할 때 - 모든 테스트 통과
그러나 [Parallelizable(ParallelScope.Children)]로 실행할 때
따라서 병렬로 실행됩니다(같은 클래스의 여러 메서드).
그러나 어떤 이유로 일부 테스트는 실패합니다.
이 클래스에는 테스트 전반에 걸쳐 사용되는 인스턴스 필드가 있으며 해당 필드는 스레드 간에 공유되는 것 같습니다.
내 말이 맞아?
해당 클래스의 인스턴스를 하나만 만들고 이 단일 개체에서 동시에 메서드를 호출합니까?
찰리풀

당신은 그것을 알아 냈어! 예, 고정 장치의 모든 테스트는 동일한 인스턴스를 사용합니다. 이것은 항상 그런 식으로 작동해 온 NUnit의 역사적 사실입니다. 테스트 케이스를 병렬로 실행하는 것과 테스트별로 수정되는 상태 중에서 선택해야 합니다. 현재로서는 방법이 없습니다.

즉, 적절한 비율의 조명기가 있는 경우 단순히 조명기를 병렬로 실행하면 좋은 성능을 얻을 수 있습니다.

[Parallelizable(ParallelScope.Children)]은
AssemblyInfo.cs 파일?

아무도 그것이 작동하는 것을 본 적이 있습니까?

2017년 6월 14일 01:37에 CharliePoole [email protected]에서 다음과 같이 썼습니다.

[이미지: 박스비] https://www.boxbe.com/overview 자동 정리: 유지
최근 1개 이메일([email protected]) 규칙 수정
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D&tc_serial=30872123699&tc_rand=2087335475&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| 규칙 삭제
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D&tc_serial=30872123699&tc_rand=2087335475&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| 중요 표시
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D%26중요%3Dtrue%26emlId%3D61187554820&tc_serial=30872123699&tc_rand=2087335475&utm_source=stf&utm_medium00content=stf&utm_medium_email&utm_campaign=이메일

당신은 그것을 알아 냈어! 예, 고정 장치의 모든 테스트는 동일한 인스턴스를 사용합니다.
이것은 항상 그런 식으로 작동해 온 NUnit의 역사적 사실입니다. 당신은해야합니다
테스트 케이스를 병렬로 실행하는 것과
테스트별로 수정됩니다. 현재로서는 방법이 없습니다.

즉, 적절한 비율의 고정 장치가 있으면 간단히 실행하십시오.
조명기를 병렬로 연결하면 좋은 성능을 얻을 수 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/nunit/nunit/issues/164#issuecomment-308157832 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAHNVuK-J-X74mlAA_eT7OX7dxs7MpoRks5sDqzLgaJpZM4CUZ8r
.

@agray 예, 사실 이것이 제가 지금 AssemblyInfo.cs를 가지고 있는 유일한 이유입니다.

안녕하세요 조셉,

AssemblyInfo.cs 파일에 어떤 병렬 처리 라인을 추가하시겠습니까?

어떤 효과가 있는지 알고 싶습니다.

건배,

앤드류

2017년 6월 14일 수요일 오후 4시 17분, Joseph Musser [email protected]
썼다:

[이미지: 박스비] https://www.boxbe.com/overview 자동 정리: 유지
최근 1개 이메일([email protected]) 규칙 수정
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D&tc_serial=30882364582&tc_rand=1974513896&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| 규칙 삭제
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D&tc_serial=30882364582&tc_rand=1974513896&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| 중요 표시
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D%26중요%3Dtrue%26emlId%3D61214070592&tc_serial=30882364582&tc_rand=1974513896&utm_source=stf&utm_medium=email&utm

@array https://github.com/array 예, 사실 그게 제가 유일한 이유입니다.
지금 AssemblyInfo.cs가 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/nunit/nunit/issues/164#issuecomment-308325726 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAHNVghNAX8CJkqAy-qhAz8bXNhZcFOQks5sD3NigaJpZM4CUZ8r
.

@agray 귀하가 질문한 내용:

c# [Parallelizable(ParallelScope.Children)]

목표를 잊지 마세요

[assembly: Parallelizable(ParallelScope.Children)]

@LirazShay NUnit을 사용하여 Selenium 테스트를 구동하고 사용자 계정에 대한 참조 및 내가 작업하고 있던 Selenium WebDriver 인스턴스에 대한 참조와 같은 항목을 유지하기 위해 고정 장치 수준 필드를 사용하여 고정 장치 내에서 병렬로 테스트를 실행할 수 없었습니다. 내가 이 문제를 해결한 방법은 각 테스트에 대해 모든 테스트 요구 사항을 캡슐화하고 끝 부분에서 깔끔하게 분해하는 IDisposable을 구현하는 "팩토리"(나는 그것이 올바른 용어인지 확신이 서지 않기 때문에 따옴표를 사용합니다)를 작성하는 것입니다. 다음과 같이 [TearDown] 또는 [OneTimeTearDown]이 필요 없는 테스트:

 public class TestFactory : IDisposable
    {
    // Instantiate a new SafeHandle instance.
    private readonly System.Runtime.InteropServices.SafeHandle handle = new Microsoft.Win32.SafeHandles.SafeFileHandle(IntPtr.Zero, true);

    // Flag: Has Disposed been called?
    private bool disposed = false;

    public TestFactory()
    {
        this.UserRepository = new List<UserAccount>();
        this.DU = new DataUtility();
    }

    // A list of users created for this test
    public List<UserAccount> UserRepository { get; private set; }

    // A very simple data layer utility that uses Dapper to interact with the database in my application 
    public DataUtility DU { get; private set; }

    // Gets a new user and adds it to the repository
    public UserAccount GetNewUser()
    {
        var ua = new UserAccount();
        this.UserRepository.Add(ua);
        return ua;
    }


    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed)
        {
            return;
        }

        if (disposing)
        {
            // Deletes all user accounts created during the test
            foreach (UserAccount ua in this.UserRepository)
            {
                try
                {
                    ua.Delete();
                }
                catch (Exception)
                {
                    // Take no action if delete fails.
                }
            }

            this.DU.DeleteNullLoginFailures(); // Cleans up the database after tests
            Thread.Sleep(1500);
        }

        this.disposed = true;
    }
}

그런 다음 테스트 내에서 다음을 수행할 수 있습니다.

[TestFixture]
public class UserConfigureTests
{
    [Test]
    public void MyExampleTest()
    {
        using (TestFactory tf = new TestFactory())
        {
            var testUser = tf.GetNewUser();

    tf.DU.DoSomethingInTheDatabase(myParameter);

    // Test actions go here, and when we exit this using block the TestFactory cleans
    // up after itself using the Dispose method which calls whatever cleanup logic you've written into it
        }
    }
}

이렇게 하면 많은 코드 중복을 피할 수 있고 테스트의 종속성을 변경해야 하는 경우 공장에서 한 번만 수행하면 됩니다. 누군가 내가 취한 전략에 대한 피드백이 있다면 감사하겠습니다!

@tparikka 나는 그 접근 방식을 나 자신에게 강력히 추천합니다.

내 AssemblyInfo 파일에 다음이 있습니다.

[어셈블리: Parallelizable(ParallelScope.Children)]
[어셈블리: LevelOfParallelism(16)]

LevelOfParallelism 속성도 더 이상 필요합니까?

2017년 6월 15일 04:37에 Joseph Musser [email protected] 은 다음과 같이 썼습니다.

[이미지: 박스비] https://www.boxbe.com/overview 자동 정리: 유지
최근 1개 이메일([email protected]) 규칙 수정
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D&tc_serial=30894750852&tc_rand=1847060911&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| 규칙 삭제
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D&tc_serial=30894750852&tc_rand=1847060911&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| 중요 표시
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D%26중요%3Dtrue%26emlId%3D61245244440&tc_serial=30894750852&tc_rand=1847060911&utm_source=stf&utm_medium_0content=stf&utm_medium_email&utm_campaign=email&utm_campaign=

@tparikka https://github.com/tparikka 바로 그 점을 적극 추천합니다.
나 자신에게 접근하십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/nunit/nunit/issues/164#issuecomment-308521058 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAHNVmEzVDbw32Xx0jkYcGK9bZW3tLvXks5sECh8gaJpZM4CUZ8r
.

아직 LevelOfParallelism 를 사용하는 방법을 살펴보지 않았습니다. 기본적으로 보유한 코어 수입니다.

테스트가 CPU 바운드가 아닌 경우 더 높은 것이 합리적입니다. 그러나 성능이 항상 그렇듯이 답은 시나리오에 따라 달라지므로 추측하는 것보다 측정하는 것이 좋습니다.

@CharliePoole TestcaseSource 하고 있지만 결과 테스트 케이스가 실제로 병렬로 실행되지 않는 것 같습니다. 다음과 같은 것이 작동할 것으로 예상됩니다.

```c#
[테스트픽스처]
클래스 역직렬화
{
공개 정적 IEnumerableShouldDeserializeAllCases() => Enumerable.Repeat(0, 5).Select(x => TimeSpan.FromSeconds(2));

    [TestCaseSource("ShouldDeserializeAllCases"), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t)
    {
        Thread.Sleep(t);
        Assert.AreEqual(1, 1);
    }
}

```

소요되는 전체 시간은 ~2가 아닌 10초입니다.

아이가 없을 것 같아서 이 경우에는
[병렬 가능(ParallelScope.All)]
또는 클래스 수준에서 속성을 이동합니다.

@ParanoikCZE 감사합니다. 나는 실제로 그 속성이 의미하는 바에 대해 맹목적으로 날아가고 있으므로 거기에 있는 모든 열거형 값을 시도했습니다. All , Children , Fixture 또는 Self 무엇을 사용하든 상관없이 실행 시간은 10초입니다(적어도 Visual Studio에서는).

방금 수업으로 옮기려고했지만 이것도 도움이되지 않는 것 같습니다.

이것이 영감의 원천입니다 :)

class Deserialization
{
    public static IEnumerable<TestCaseData> ShouldDeserializeAllCases
    {
        get
        {
            for (int i = 1; i <= 5; i++)
                yield return new TestCaseData(TimeSpan.FromSeconds(i)).SetName($"Thread_worker_{i}");
        }
    }

    [TestCaseSource(nameof(ShouldDeserializeAllCases)), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t) => System.Threading.Thread.Sleep(t);
}

@ParanoikCZE 다시 한번 감사드립니다. Visual Studio에서 이것을 테스트했는데 시각화가 훨씬 더 명확해졌지만 테스트는 여전히 순차적으로 실행되고 있습니다. 단계를 늘리는 대신 각 테스트 케이스에 대해 일정한 절전 모드를 사용하면 더 쉽게 확인할 수 있습니다.

AssemblyInfo에 [assembly: LevelOfParallelism(5)]을 추가해 보세요. 기본값이 있는 것 같지만 어떻게든 작동하지 않을 수 있습니다. 어쨌든, 나는 아이디어가 없다. :)