오늘도 여전히 Debug.Assert를 사용해야합니까?

나는 최근에 많은 Debug.Assert (C #)와 함께 새로 작성된 코드를 발견했습니다.

일반적으로 TDD, BDD 및 단위 테스트를 사용 함에도 불구하고 여전히 이것을 널리 사용해야합니까?

Assert를 사용하지 말아야 할 이유가 없습니다. 그렇게함으로써, 당신은 이미 전제 조건과 불변 인과 같은 경비원의 필요성을 인정했고 계약에 의한 설계 로 나아가고 있습니다. Assert는 이것을 달성하는 한 가지 방법 일뿐입니다 ...

// Precondition using Asert
void SomeMethod(Foo someParameter)
{
    Debug.Assert(someParameter != null)
}

// Precondition using If-Then-Throw
void SomeMethod(Foo someParameter)
{
    if (someParameter == null)
        throw new ArgumentNullException("someParameter");
}

// Precondition using Code Contracts
void SomeMethod(Foo someParameter)
{
    Contract.Requires(someParameter != null);
}

// Precondition using some custom library
void SomeMethod(Foo someParameter)
{
    Require.ArgumentNotNull(() => someParameter);
}

모두 같은 것을 달성하는 방법입니다 : 코드의 견고성. 옵션을 선택하면 Assert가 올바른 선택입니다.

유닛 테스트는 지금까지 전혀 다른 것을 달성하지 않았으므로 언급하지 않았습니다. 단위 테스트는 가드를 실행하여 코드의 견고성을 공식적으로 증명합니다.

[Test]
void SomeMethod_WhenGivenNull_ThrowsArgumentNullException()
{
    delegate call = () => someObject.SomeMethod(null);

    Assert.That(call).Throws<ArgumentNullException>();
}

이것은 완전히 다른 종류의 주장입니다 ...

** 일부 프레임 워크에서는 어설 션 오류로 인해 전체 런타임이 중단 될 수 있으므로 다른 옵션 중 하나가 선호 될 수 있으므로 어설 션 오류에 대한 단위 테스트는 실제로 매우 어렵습니다. *

Asserts와 Unit Test는 내 도구 상자에서 서로 다른 두 가지 도구라고 생각합니다. 어떤 것들은 한 가지에 더 적합하고 어떤 것들은 다른 것에 더 적합합니다.

예를 들어, 요즘 저는 주로 비공개 메소드의 매개 변수를 검증하기 위해 어설 션을 사용합니다.

요즘 Debug.Assert를 조기 최적화로 봅니다. 실제로 성능이 필요하지 않은 경우 릴리스 모드에서 Assert를 억제하면 버그를 더 오래 숨길 수 있습니다.

MattDavey가 지적한 것처럼 코드 계약 은 동적 검사 대신 정적 검사를 제공하는 것이 우수 할 수 있으며, 사용할 수없는 경우 Trace.Assert 또는 평범한 오래된 것을 선호합니다.if(x) throw SomeException;