assert.fail ()가 나쁜 연습으로 간주됩니까?

Question

TDD를 할 때 Assert.Fail을 많이 사용합니다. 나는 보통 한 번에 한 번의 테스트를 진행하고 있지만 나중에 구현하고 싶은 아이디어를 얻을 때 테스트 방법의 이름이 일종의 할 일 목록으로 구현하려는 것을 나타내는 빈 테스트를 신속하게 작성합니다. 내가 잊지 않기 위해 나는 신체에 assert.fail ()을 넣습니다.

xunit.net을 시험해 볼 때 Assert.fail을 구현하지 않았다는 것을 알았습니다. 물론 당신은 항상 assert.istrue (false)를 할 수 있지만 이것은 내 의도도 전달하지는 않습니다. 나는 인상을 얻었습니다. 이것은 나쁜 연습으로 간주됩니까? 그렇다면 왜?

---

@martin meredith 그게 내가하는 일이 아닙니다. 먼저 테스트를 작성한 다음 코드를 구현하여 작동합니다. 보통 나는 한 번에 여러 테스트를 생각합니다. 아니면 다른 작업을 할 때 글을 쓸 테스트에 대해 생각합니다. 그때는 기억하기 위해 빈 실패 테스트를 작성합니다. 나는 시험을 쓸 때까지 나는 테스트 우선을 깔끔하게 일한다.

@jimmeh는 좋은 생각처럼 보입니다. 무시 된 테스트는 실패하지 않지만 여전히 별도의 목록에 나타납니다. 그것을 시도해야합니다.

@matt Howells 좋은 아이디어. NotimplementedException이 경우 Assert.fail ()보다 의도를 더 잘 통신합니다.

@Mitch Wheat 그게 내가 찾고 있던 것입니다. 내가 그것을 남용하는 다른 방식으로 남용되는 것을 막기 위해 제외 된 것 같습니다.

Answer 1

이 시나리오에서 Assert.fail을 호출하는 대신 다음을 수행합니다 (C# / Nunit).

[Test]
public void MyClassDoesSomething()
{
    throw new NotImplementedException();
}

Assert.fail보다 더 명백합니다.

Assert.fail ()보다 더 명백한 주장을 사용하는 것이 바람직하다는 일반적인 합의가있는 것 같습니다. 대부분의 프레임 워크는 더 나은 대안을 제공하지 않기 때문에 그것을 포함해야합니다. 예를 들어, NUNIT (및 기타)는 일부 코드가 특정 클래스의 예외를 던지는 것을 테스트하기 위해 expectionExceptionAttribute를 제공합니다. 그러나 예외의 속성이 특정 값으로 설정되어 있음을 테스트하기 위해 사용할 수 없습니다. 대신 assert.fail에 의지해야합니다.

[Test]
public void ThrowsExceptionCorrectly()
{
    const string BAD_INPUT = "bad input";
    try
    {
        new MyClass().DoSomething(BAD_INPUT);
        Assert.Fail("No exception was thrown");
    }
    catch (MyCustomException ex)
    {
         Assert.AreEqual(BAD_INPUT, ex.InputString); 
    }
}

xunit.net 메소드 assert.throws는 assert.fail 메소드를 필요로하지 않고 이것을 훨씬 더 깔끔하게 만듭니다. Assert.fail () 메소드를 포함시키지 않으면 xunit.net은 개발자가보다 명백한 대안을 찾고 사용하고 필요한 경우 새로운 주장의 생성을 지원하도록 권장합니다.

Answer 2

의도적으로 제외되었습니다. 이것은 Assert.fail ()가없는 이유에 대한 Brad Wilson의 답변입니다.

우리는 실제로 이것을 간과하지 않았습니다. 나는 assert.fail을 찾았다. 때로는 테스트가 구성되는 방식 일 뿐이며 때로는 Assert가 다른 주장을 사용할 수 있기 때문입니다.

Answer 3

나는 항상 테스트가 단순한 값 비교를 넘어 논리를 통해 실패해야한다는 것을 감지 한 경우 Assert.fail ()을 사용했습니다. 예로서:

try 
{
  // Some code that should throw ExceptionX
  Assert.Fail("ExceptionX should be thrown")
} 
catch ( ExceptionX ex ) 
{
  // test passed
}

따라서 프레임 워크에서 assert.fail ()의 부족은 나에게 실수처럼 보입니다. Assert 클래스를 패치하여 FAIL () 메소드를 포함하여 패치를 프레임 워크 개발자에게 제출하고 추가 한 추론을 제안합니다.

작업 공간에서 의도적으로 실패한 테스트를 만드는 연습에 관해서는, 커밋하기 전에 자신을 구현하도록 상기시키기 위해, 그것은 나에게 좋은 연습처럼 보입니다.

Answer 4

장치 테스트에 mbunit을 사용합니다. 테스트 스위트에서 테스트를 무시할 수있는 옵션이 있습니다. 테스트 스위트에서 주황색 (녹색 또는 빨간색이 아닌)으로 표시됩니다. 아마도 Xunit은 비슷한 것을 가지고있을 것입니다. 그리고 당신이 그 방법에 어떠한 주장도 놓을 필요조차 없다는 것을 의미 할 것입니다. 왜냐하면 그것이 다른 색상으로 표시되기 때문에 놓치기가 어렵 기 때문에?

편집하다:

MBUNIT에서는 다음과 같은 방식입니다.

[Test]
[Ignore]
public void YourTest()
{ } 

Answer 5

이것은 디자인으로 예외를 던지고 싶은 코드 테스트를 작성할 때 사용하는 패턴입니다.

[TestMethod]
public void TestForException()
{
    Exception _Exception = null;

    try
    {
        //Code that I expect to throw the exception.
        MyClass _MyClass = null;
        _MyClass.SomeMethod();
        //Code that I expect to throw the exception.
    }
    catch(Exception _ThrownException)
    {   
        _Exception = _ThrownException
    }
    finally
    {
        Assert.IsNotNull(_Exception);
        //Replace NullReferenceException with expected exception.
        Assert.IsInstanceOfType(_Exception, typeof(NullReferenceException));
    }
}

IMHO 이것은 assert.fail ()를 사용하여 예외를 테스트하는 더 나은 방법입니다. 그 이유는 예외를 전혀 테스트 할뿐만 아니라 예외 유형을 테스트하기 때문입니다. 나는 이것이 Matt Howells의 답과 비슷하다는 것을 알고 있지만 마지막으로 블록을 사용하는 IMHO는 더 강력합니다.

분명히 예외 입력 문자열 등을 테스트하기위한 다른 어제 방법을 포함하는 것이 여전히 가능할 것입니다. 나는 내 패턴에 대한 귀하의 의견과 견해에 감사 할 것입니다.

Answer 6

개인적으로 나는 테스트 스위트를 이와 같은 할 일 목록으로 사용하는 데 아무런 문제가 없습니다. 결국 테스트를 작성하는 한 ~ 전에 전달할 코드를 구현합니다.

그러나 나는이 접근법을 직접 사용했지만 지금은 그렇게하는 것이 너무 많은 테스트를 선행으로 쓰는 길을 이끌어 낸다는 것을 알게되었지만, 이상한 방식으로는 테스트를 전혀 쓰지 않는 역 문제와 같습니다. 당신은 결국 너무 일찍 IMHO에 대한 디자인에 대한 결정을 내립니다.

우연히 MSTEST에서 표준 테스트 템플릿은 샘플 끝에 Assert.Inclusible을 사용합니다.

afaik xunit.net 프레임 워크는 매우 가벼우려고 의도되었으며, 개발자가 명시 적 실패 조건을 사용하도록 장려하기 위해 고의적으로 실패했습니다.

Answer 7

Wild Propess : 원천 징수 assert.fail은 테스트 코드를 작성하는 좋은 방법이 거대한 스파게티의 힙으로 악의적 인 경우에 assert.fail로 이어지는 것을 막기위한 것입니다. [추가 편집 : 다른 사람들의 답변은 이것을 광범위하게 확인하지만 인용문

그것이 당신이하는 일이 아니기 때문에 xunit.net이 과도하게 보호 될 수 있습니다.

아니면 그들은 단지 그것이 불필요한 것만 큼 드물고 정교하다고 생각할 수도 있습니다.

나는 thiscodehasnotbeenwrittenyet (실제로 타이핑하기 쉽기 위해 더 짧은 것)이라는 함수를 구현하는 것을 선호합니다. 그보다 더 명확하게 의도를 전달할 수 없으며 정확한 검색어가 있습니다.

실패했거나 구현되지 않은지 (링커 오류를 유발하기 위해) 또는 컴파일하지 않은 매크로 인 경우 현재 선호도에 맞게 변경할 수 있습니다. 예를 들어 무언가를 실행하고 싶을 때 ~이다 끝났어, 당신은 실패를 원합니다. 당신이 그들 모두를 제거하기 위해 앉아있을 때, 당신은 컴파일 오류를 원할 수 있습니다.

Answer 8

좋은 코드로 나는 보통 :

void goodCode() {
     // TODO void goodCode()
     throw new NotSupportedOperationException("void goodCode()");
}

테스트 코드를 사용하면 일반적으로 수행합니다.

@Test
void testSomething() {
     // TODO void test Something
     Assert.assert("Some descriptive text about what to test")
}

Junit을 사용하고 실패를 원하지 않지만 오류가 발생하면 일반적으로 다음과 같습니다.

@Test
void testSomething() {
     // TODO void test Something
     throw new NotSupportedOperationException("Some descriptive text about what to test")
}

Answer 9

조심하십시오 Assert.Fail 그리고 개발자가 어리 석거나 깨진 테스트를 작성하도록하는 부패한 영향. 예를 들어:

[TestMethod]
public void TestWork()
{
    try {
        Work();
    }
    catch {
        Assert.Fail();
    }
}

시도 캐치가 중복되기 때문에 이것은 바보입니다. 예외가 발생하면 테스트가 실패합니다.

또한

[TestMethod]
public void TestDivide()
{
    try {
        Divide(5,0);
        Assert.Fail();
    } catch { }
}

이것은 깨졌고 테스트는 항상 분열 기능의 결과를 전달합니다. 다시, 예외가 발생하는 경우에만 테스트가 실패합니다.

Answer 10

예외를 던져야한다고 말하면 Assert.fail을 사용하겠습니까? 불필요합니다. 예상 exception 속성 만 사용하지 않는 이유는 무엇입니까?

Answer 11

실패한 테스트를 작성한 다음 코드를 작성한 다음 테스트를 작성하십시오. 이것은 테스트 중심의 개발이 아닙니다.

기술적으로 테스트 중심 개발을 올바르게 사용하는 경우 Assert.fail ()이 필요하지 않아야합니다.

TODO 목록을 사용하거나 작업에 GTD 방법론을 적용 할 생각을 했습니까?

Answer 12

MS 테스트가 있습니다 assert.fail () 그러나 그것은 또한 가지고 있습니다 assert.inconclusive (). Assert.fail ()에 가장 적절한 용도는 좋은 예를 생각할 수는 없지만 어셈블리를 어색하게 할 인라인 논리가있는 경우라고 생각합니다. 대부분의 경우 테스트 프레임 워크가 assert.fail () 이외의 다른 것을 지원하는 경우 사용하십시오.

Answer 13

나는 당신이 (선불) 테스트가 무엇을 해야하는지 스스로에게 물어봐야한다고 생각합니다.

먼저, 당신은 구현없이 (세트) 테스트를 작성합니다. 어쩌면 비오는 날 시나리오 일 수도 있습니다.

이러한 모든 테스트는 올바른 테스트가 되려면 실패해야합니다. 따라서 두 가지를 달성하려고합니다. 1) 구현이 올바른지 확인하십시오. 2) 단위 테스트가 올바른지 확인하십시오.

이제 TDD를 선불로 사용하면 모든 테스트, NYI 부품을 실행하려고합니다. 총 테스트 실행 결과는 다음과 같은 경우 : 1) 모든 구현 된 물건이 성공합니다 2) 모든 NYI 재료가 실패합니다.

결국, 구현이없는 동안 단위 테스트가 성공하면 단위 테스트 OMMISS가 될 것입니다.

당신은 구현 된 모든 구현 및 구현되지 않은 코드를 점검하고 구현 된 코드가 실패하거나 구현되지 않은 코드가 성공한 경우 전송되는 Continous Integration Test의 메일로 끝나려고합니다. 둘 다 바람직하지 않은 결과입니다.

무시] 테스트를 작성하면 작업을 수행하지 않습니다. 테스트에서 다른 테스트 라인을 실행하지 않고 첫 번째 어제 실패를 중지시키는 어설 션도 없습니다.

자, 어떻게 이걸 달성 하는가? 테스트의 고급 조직이 필요하다고 생각합니다. 그리고 이러한 목표를 달성하기 위해 다른 메커니즘이 필요합니다.

테스트를 나누고 완전하게 실행되지만 실패 해야하는 테스트를 만들어야한다고 생각합니다.

아이디어는 여러 어셈블리를 통해 테스트를 분할하고 테스트 그룹화를 사용하는 것입니다 (MSTEST의 주문 테스트는 작업을 수행 할 수 있음).

그럼에도 불구하고 NYI 부서의 모든 테스트가 실패하지 않으면 우편으로 우송하는 CI 빌드가 쉽고 간단하지는 않습니다.