Nunit: AssertionException을 잡으면 3.10 이후 테스트가 실패합니다.

귀하의 테스트는 NUnit의 작동 방식에 대한 두 가지 제안을 테스트하고 있습니다.

1. 모든 어설션 실패는 AssertionException을 발생시킵니다.
2. 예외를 잡는 것은 오류가 보고되는 것을 방지합니다.

첫 번째 문장은 대부분 사실이지만 여러 주장 블록 내에서 또는 경고를 발행할 때 유지되지 않습니다. 두 번째는 전혀 사실이 아닙니다. 예외를 잡을 때까지는 이미 실패가 기록된 것입니다. 이것은 NUnit의 내부 동작의 변경으로, 이러한 예외를 포착하는 경우에만 관찰할 수 있습니다. 예를 들어, 저는 사람들에게 몇 년 동안 그러한 행동에 의존하지 말라고 말했습니다. 왜냐하면 그것은 단지 구현의 우연에 불과하기 때문입니다.

귀하의 샘플 코드는 귀하가 보고 있는 문제를 설명하기 위한 것일 뿐입니다. 예외를 잡기 위해 실제로 수행하려는 작업의 예를 제공할 수 있습니까? 더 나은 솔루션을 찾는 데 도움을 드릴 수 있다고 확신합니다.

이렇게 짧은 시간에 다시 연락해 주셔서 감사합니다. 나는 상황이 아직 불안정할 때 메커니즘을 사용합니다. 따라서 때때로 소프트웨어가 제대로 작동하지 않습니다. 이 경우 개발자에게 보고합니다. 그동안 우리는 이 불안정한 동작을 해결하기 위해 테스트를 확장했습니다. 따라서 이 문제에서 실패하는 대신 테스트가 통과합니다.

이를 위해 Warn.If() 메서드를 사용해 보았지만 테스트 탐색기에서 결과가 "Test Skipped"로 설정됩니다. 테스트를 전혀 건너뛰지 않기 때문에 보고 실패가 발생합니다. 따라서 대신 어설션 catch를 구현하고 경고를 추적하도록 선택합니다. 나는 그것이 바람직하지 않다는 것을 알고 있지만 꽤 잘 작동했습니다. 적어도 마지막 업데이트까지는.

이 변경이 의도적인 것인지 궁금합니다. 그런 경우에는 변경해야 함을 압니다.

Warn.If 잘 작동합니다 ... 테스트 탐색기에서 __except__. 😢 문제는 테스트 탐색기가 합격과 불합격은 알지만 경고는 모른다는 것입니다. 경고 결과 상태를 구현할 때까지 경고 결과를 이해할 수 있는 것으로 번역해야 했습니다. FWIW는 Inconclusive 결과 상태와 유사한 문제가 있습니다.

우리가 만든 변경은 의도적이었고 오랫동안 계획되어 왔습니다. 우리는 너무 많은 시간 동안 예외에 의존하고 싶지 않으며 테스트를 중단하지 않는 방식으로 어설션의 결과(결국 통과된 것을 포함하여)를 보고하고 싶습니다. 귀하와 같은 사용자에게 미치는 영향을 완화하기 위해 몇 가지 변경 사항을 적용했지만 완화할 수 있는 방법이 없는 것 같습니다.

불안정한 테스트가 있는 경우 수년간 표준은 테스트를 무시하는 것이었습니다. 불행히도 많은 팀이 "무시된 테스트를 무시"하므로 좋은 선택이 아닙니다. 팀에서 경고를 심각하게 받아들이도록 훈련할 수 있다면(사실상 오류 및 실패만큼이나 심각하게) 경고 상태를 사용하여 취약성을 강조할 수 있습니다. 또 다른 가능성은 종료 속성과 함께 무시를 사용하여 특정 날짜까지 수정되지 않으면 실패로 변경되도록 하는 것입니다.

BTW, 내가 팀을 지도할 때 나는 보통 무시된 테스트의 Big Visible Display를 지속적으로 업데이트합니다. 대부분의 팀에서는 누가 무엇을 담당하는지 알고 있으므로 실제로 비정상적 테스트를 담당하는 사람을 부를 필요가 없습니다. 모든 사람이 문제를 볼 때 해결되는 경향이 있습니다.

@svanimpelen 비정상적 테스트에 Retry 속성을 사용해 보셨습니까 ? 여러 번 실행하여 통과하도록 할 수 있습니다.

탐색기에서 테스트를 건너뛰는 경고로 인해 현재 지원하는 MSTest의 제한된 수보다 더 많은 결과 상태를 지정할 수 있도록 Visual Studio 팀과 논의했습니다. 그들은 아이디어를 좋아하므로 앞으로 개선 사항을 볼 수 있기를 바랍니다. 그때까지 당신은 건너 뛰는 고통을해야합니다. 즉, 건너뛰면 경고가 표시됩니다. 나는 당신이 경고가 매우 명확하기를 원했다고 가정합니다 😄

API가 실패 시 AssertionException을 발생시킨다는 많은 메소드가 문서화되어 있습니다.

https://github.com/nunit/nunit/blob/d03e93c8f25170a8ff48e80863a3fe6fd294613a/src/NUnitFramework/framework/Assert.That.cs#L40 -L43

이 문서와 NUnit의 오랜 동작이 3.10의 주요 변경 사항을 구성하지 않습니까?
내가 놓치고 있는 것이 없다면 적어도 지금은 잘못된 문서를 제거해야 합니다.

여러 어설션 블록을 도입했기 때문에 문서가 오해의 소지가 있다는 점에 동의합니다. 즉, 이 경우에는 AssertionException 가 계속 발생하고 있지만 차이점은 예외가 포착되었음에도 불구하고 이제 테스트가 Visual Studio에서 실패로 보고된다는 것입니다. 나는 그것을 획기적인 변화로 보지 않습니다. 사용자는 문서화되지 않은 행동에 의존하고 있었습니다. 나에게 그것은 테스트를 주문하기 위해 알파벳 순서로 테스트가 실행되었다는 사실에 의존하는 사용자와 다르지 않습니다.

문서를 업데이트해야 합니다. 예외 발생에 대한 정보를 제거하고 대신 false 조건이 테스트에 실패했다고 명시할 수 있습니다. 그리고/또는 다중 주장 블록에서 예외가 발생하지 않는다고 말할 수 있습니까? 개인적으로 throw되는 예외 유형은 내부 세부 정보라고 생각하므로 첫 번째 옵션을 선호합니다.

맞다고 생각합니다. 예외 사용이 어디에나 문서화되어야 하는 경우 내부의 위키 섹션에 있을 수 있습니다.

메서드 문서에 예외가 발생한다고 명시되어 있는 경우 호출 사이트에서 예외가 발생할 수 있다는 것이 명백하다고 생각합니다. C#에는 확인된 예외가 없으며 XML 문서는 메서드 계약의 해당 부분을 통신하는 방법입니다. 내가 아는 한 "throws X"라는 언어는 항상 메소드가 그것을 잡지 못한다는 것을 의미했기 때문에 나는 여전히 다른 사람들이 그것을 어떻게 받아들였는지 약간 걱정됩니다. 위키의 주요 변경 사항이 안전한 쪽에 있을 수 있습니까?

XML 문서에서 AssertionException에 대한 모든 참조를 제거하고 사람들에게 AssertionException을 사용하지 않도록 경고하는 위키 페이지를 만드는 아이디어가 마음에 듭니다.

💭 AssertionException 잡는 것이 항상 버그라면, 그 유형을 내부적으로 만드는 것을 고려할 수 있습니까?

@jnm2.

나는 XML 문서의 중요성에 동의하지만 사실 그 문서는 우리가 지금까지 계약의 일부를 통신해온 방식이 __아닙니다__. 나는 실제로 당신이 그것을 제안한 첫번째 사람일지도 모른다고 생각하고 나는 그것이 좋은 생각이라고 생각합니다.

하지만 그런 식으로 생각하기 시작하면 많은 잘못된 댓글을 변경해야 한다는 점을 인식해야 한다고 생각합니다! 나는 우리가 이러한 각각의 문서 변경 사항을 주요 변경 사항으로 취급할 수 있다고 생각하지 않습니다. 경우에 따라 기본 동작 변경을 중단으로 합리적으로 처리할 수 있지만 이는 다릅니다. 문서 변경 사항이 깨지지 않아야 합니다.

이것은 주요 변경 목록에 무엇이 있어야 하는지에 대한 질문을 제기합니다. 귀하의 과거 의견을 이해했다면 사용자에게 피해를 줄 수 있는 모든 것을 문서화하려는 경향이 있다고 생각합니다. 나는 많은 사용자를 망칠 것이라고 생각하는 것을 문서화하는 것을 선호합니다.

차이점을 확인하는 방법은 다음과 같습니다. 다른 사람들은 동의하지 않을 수 있습니다. __파괴될 수 있는 모든 것__을 문서화하는 것은 나에게 CYA와 같은 냄새가 납니다. 마치 경영진이 실패 자체를 예방하기보다 누가 실패의 책임을 지는지에 집중할 때 때때로 탐닉하는 종류의 CYA와 같습니다. 만약 우리가 모든 것을 문서화한다면, 우리는 말할 수 있습니다... "봐, 우리는 덮여있다." 우리가 중요하다고 생각하는 것만 문서화하면 잘못되고 사과해야 할 위험이 있지만 일반 사용자는 변경 사항 집합을 훨씬 더 쉽게 이해할 수 있습니다. 나는 후자를 선호한다.

어설션 예외를 잡는 것이 안전한 경우가 있습니다. 예를 들어, TestExecutionContext가 관련되지 않고 테스트를 직접 실행할 때 안전하게 유지되도록 얼마 전에 변경했습니다. 예외를 내부적으로 만들면 예외가 발생합니다. 사실 깨서 기뻤는데 팀에서 안된다고 해서 수정했습니다. 무엇을 깨고 싶은지 결정하기만 하면 됩니다. 그 수정은 메서드를 호출하는 코드가 아니라 테스트 자체 내부에서 예외를 잡는 것을 처리하는 현재 문제를 처리하지 __하지__ 않았습니다.

테스트에서 AssertionException을 잡는 것은 내가 고전적인 "냄새"라고 부르는 것입니다. 틀릴 수도 있겠지만 구체적인 사례를 살펴봐야 알 수 있다. 나는 사용자에게 "Catching AssertionException은 NUnit 내부에 대한 자세한 지식이 없는 한 오류일 가능성이 높습니다. 올바른 동작을 보장하려면 테스트 결과를 변경하려고 하지 말고 원하는 작업을 수행한 후 예외를 다시 발생시켜야 합니다. 그것으로." 그러나 나는 여전히 그러한 정보가 XML 문서 또는 일반 사용자 문서에 속한다고 생각하지 않습니다. 내부 섹션에 페이지로 넣을 것입니다.

BTW, 내 과거 경험은 무언가를 문서화한 다음 사람들에게 사용하지 말라고 말하면 사용량이 증가한다는 것입니다. 😄

좋은 점, 감사합니다! 나는 부분적으로 CYA의 관점에서 생각하고 있다고 생각합니다. 또 다른 요소도 있습니다. 라이브러리의 소비자로서 저는 개인적으로 모든 주요 변경 사항을 듣는 것에 감사하여 제 코드에서 잘못된 가정을 찾을 수 있습니다. 특히 컴파일러가 알아차리지 못하는 이와 같은 변경 사항의 경우. 나는 그것을 감사하게 생각하기 때문에 어느 정도 사용자에게 투영합니다.

문서 수정 사항을 추적하기 위해 새 문제를 시작해야 합니까?

왜 새로운가?

제목은 수정하기보다는 답변된 질문으로 닫을 것 같습니다. 일반적으로 제목을 변경하고 이 문제를 사용하여 문서 변경 사항을 추적합니까?

내가 일반적으로 한 일은 문제를 검토하고 분류하는 것입니다. 이 경우에는 문서 문제로 분류합니다. 분명히, 우리는 가능한 버그로 먼저 논의하는 데 정말 오랜 시간을 보냈습니다. 프로젝트 관리에 관한 질문입니다. 실제로는 제 범위 밖입니다.

내 말은 논리적이고 일관성 있는 일을 하라는 것입니다. 😄 버그가 아니므로 닫는 것은 옵션입니다. 그러나 이는 불만 사항과 솔루션을 구분합니다. 문서 버그로 재분류하고 제목을 편집할 때 설명 댓글을 작성하면 불만 사항이 있는 솔루션을 유지할 수 있습니다. 어떤 경우든 Done issues의 이슈 제목은 릴리스 노트에서 끝나므로 발생한 일을 표현해야 합니다.

예외를 잡기 위해 실제로 수행하려는 작업의 예를 제공할 수 있습니까? 더 나은 솔루션을 찾는 데 도움을 드릴 수 있다고 확신합니다.

3.10으로 업그레이드한 후 테스트가 실패하기 시작했기 때문에 현재 동일한 문제에 직면하고 있습니다. 이제 여기 내 문제가 있습니다.
사용자 정의 테스트 어설션 방법이 있습니다. 내부적으로 NUnit.Assert를 호출합니다. 나는 이러한 어설션 메서드를 테스트하여 실패할 것으로 예상할 때 실제로 실패하는지 확인합니다.
현재 내 테스트는 AssertionException 를 포착하여 사용자 지정 어설션 메서드가 테스트를 실패하게 하지만 업그레이드 후에는 위의 이유로 모든 테스트가 실패하기 시작합니다.

3.10에서 권장되는 테스트 방법은 무엇입니까?

감사 해요.

가장 간단한 접근 방식은 직접 수행하는 대신 Assert.Throws를 사용하여 예외를 catch하는 것입니다. Assert.Throws는 NUnit 내부를 이해하고 실패가 보고되지 않도록 합니다.

나는 요전날 알림에서 이것을 보았고 그것에 대해 많이 생각하지 않았습니다. 그러나 논리 내에서 "Assert.That"을 수행하는 라이브러리 프로젝트 업데이트(테스트 도우미 프레임워크입니다. 특히 EF 컨텍스트 및 엔터티를 직접 코딩하고 해당 데이터베이스를 코딩할 때 EF 지속성을 테스트하는 쉬운 방법을 제공하기 위한 것입니다. 수동 마이그레이션(또는 FluentMigrator와 같은 도구 사용) -- 즉, 호출자를 대신하여 어설션을 수행 해야 하므로 이제 테스트가 실패해서는 안 되는 곳에서 테스트가 실패합니다. 특히 한 테스트가 어설션하는 특정 조건은 테스트 실패를 발생시켜야 합니다. 하지만 "catch"가 더 이상 항상 그랬던 것처럼 작동하지 않기 때문에 이러한 테스트는 실제로 통과하는 동안 실패한 것으로 보고됩니다.

따라서 적절한 NUnit 어설션을 던질 수 없거나 사용자를 위해 지루한 작업을 수행하여 더 빠른 테스트 개발을 지원하기 위한 라이브러리 코드에서 Assert.That 를 사용할 수 없습니까?

사용자가 예외를 사용할 수 없는 경우 사용자가 예외를 throw할 수 없어야 한다는 이전 진술에 동의합니다. 그러나 소비자와 테스트를 위해 Assert.That 코드가 있는 문제는 해결되지 않습니다. 코드가 nunit 어설션으로 실패하기 때문에 실패를 던진다는 것을 증명하기 위한 테스트입니다.

결과 API 중 일부를 제품화해야 할까요?

@fluffynuts 내가 당신을 올바르게 이해한다면 catch 절은 사용자 라이브러리의 코드가 아니라 테스트 코드에 있습니다. (사용자 라이브러리에도 있다면 이에 대해 이야기할 수 있지만 문제는 약간 다릅니다.)

물론 NUnit에는 자체 테스트가 있으므로 이 변경 사항이 적용될 때와 정확히 동일한 잠재적 문제가 있었습니다. 당연히 테스트를 계속 통과하도록 자체 테스트를 수정했습니다. 당신은 같은 일을 할 수 있습니다.

첫 번째 방어선은 Assert.Throws 입니다. 테스트 실패 동작의 대부분의 경우 try / catch(AssertionException) 를 Assert.Throws<AssertionException> 직접 바꿀 수 있습니다. 내부적으로 Assert.Throws 는 TestExecutionContext 를 분리하여 실제 테스트 결과가 테스트 중인 오류로 인해 오염되지 않도록 합니다.

어떤 경우에는 고유한 격리 컨텍스트를 만들어야 할 수도 있습니다. Assert.Throws 대한 코드를 검사하여 이를 수행하는 방법을 볼 수 있습니다.

그러나 NUnit의 자체 실패 테스트의 대부분은 실제로 다른 접근 방식을 사용합니다. 자체 테스트 프로그램에서 실행되는 테스트가 포함된 별도의 어셈블리가 있습니다. 결과를 캡처한 다음 검토할 수 있습니다. 이것은 더 많은 작업이지만 NUnit에 대한 구현 세부 정보를 테스트에 너무 많이 넣는 것을 방지합니다. 이를 수행하는 대부분의 방법은 테스트 유틸리티 어셈블리에서 찾을 수 있습니다. 나는 그것이 @jnm2 가 말하는 것이라고 생각합니다.

질문이 있으면 게시하거나 오프라인으로 연락하여 이에 대한 추가 도움을 받으세요.

정보에 대해서 감사드립니다. 예, 어설션은 테스트 코드 내에서 포착됩니다. Assert.Throws는 일반적으로 트릭을 수행하지만 문제의 특정 테스트는 데이터베이스에서 가져와야 하는 날짜/시간 값을 테스트하는 데 허용되는 델타가 "너무 낮음"으로 라이브러리 코드를 실행합니다. 대부분의 경우 localdb로의 드리프트는 1ms이지만 때로는 더 높게 드리프트됩니다. 이 테스트는 "가끔" 발생한다고 단언하는 것을 목표로 합니다. 그래서 현재 4개의 병렬 스레드에서 코드를 10번 실행하고 적어도 한 번은 실패할 것으로 예상합니다. Assert.Throws는 불행히도 이 경우에 너무 결정적이므로 nunit 예외(또는 라이브러리 코드 내에서 Assert) 사용을 중단하거나 여러분이 사용하는 fu를 배워야 합니다. 원하는 경우 오프라인에서 발생할 수 있는 모든 지침에 감사드립니다.

헐, 내가 보고 있던 AsyncVoidVerificationScope에 대한 메시지 펌프 테스트 실패가 @fluffynuts 가 겪고 있는 것과 정확히 같은 문제라는 것을

어쨌든, 내가 하고 싶은 것은 Assert.Throws 가 하는 것처럼 using (new TestExecutionContext.IsolatedContext()) 에서 대리자 호출을 래핑하는 것입니다.

Assert.Throws 및 Assert.ThrowsAsync 는 비동기 대리자를 호출하기 전에 격리된 컨텍스트를 설정하지 않습니다. 왜 이런거야?

@fluffynuts 오래전에 내가 Assert.Catch 처음 썼을 때 예외가 발생했을 뿐 예외가 발생하지 않으면 오류가 발생하지 않았습니다. 불행히도 변경되어 더 이상 Assert.Throws 해당하는 "중립"이 없습니다. 그러나 당신은 하나를 쓸 수 있습니다. 다음은 Assert.Throws 의 코드를 기반으로 하는 테스트되지 않은 버전입니다. 동기 코드만 처리하지만 Assert.Throws 코드를 사용하여 비동기로 쉽게 확장할 수 있습니다.

```C#
공개 정적 무효 예외 SafelyCatchAnNUnitException(TestDelegate 코드)
{
예외 catchException = null;

using (new TestExecutionContext.IsolatedContext())
{
    try
    {
        code();
    }
    catch (Exception ex)
    {
        caughtException = ex;
    }

    return caughtException;
}

}
```

이 메서드는 NUnit의 assert 메서드가 남긴 오류의 나머지 부분을 정리하여 throw된 모든 예외를 반환합니다. 예외가 발생하지 않으면 null을 반환합니다.

코드에서 더 높은 수준에서 IsolatedContext() 를 사용하여 실제 테스트 결과를 검색하는 것도 가능합니다. 그러면 예외에 대한 참조 없이 테스트 결과 수준에서 완전히 테스트할 수 있습니다. 나는 NUnit이 현재 자체 테스트를 수행하는 방식보다 우수할 것이라고 생각하는 이러한 유형의 테스트를 위한 라이브러리를 작성하는 것에 대해 약간의 생각을 했습니다.