테스트 방법에서 try catch를 사용해야합니까?

18

단위 테스트를하고 있습니다.

하나의 기능을 테스트하려고합니다.

테스트 컴포넌트에서 호출합니다. 그러나 원격 기능이 예외를 처리 할 수 없다면 내 테스터 구성 요소에서도 예외가 발생합니다.

테스터 구성 요소에서 예외가 발생하는 것에 대해 걱정해야합니까?

감사.

편집하다:

추신:

오류를 던지는 것은 좋지만 다른 기능에 대해서만 최종 옵션이 될 때까지 최종 옵션이 아닙니다!

세상에 나는 프로그래밍 견적을 썼다!!

testing unit-testing exceptions

— 비 카스
소스

나는 테스트를 처음 접했고 함수의 동작 만 테스트해야한다. 블랙 박스 및 화이트 박스 테스트라고합니다. 아 기억 나 나는 대학에서 그것을 공부했다!

— Vikas

구체적으로 어떤 언어와 xUnit 프레임 워크를 사용하고 있습니까? 어떤 경우에는 그렇습니다.

— Greg K

내가 사용하고 MXUnit 와 MockBox 및 냉각 박스를 ColdFusion에서의 언어.

— Vikas

23

짧은 대답 : NO.

단위 테스트에서 예외를 포착하지 마십시오. 예외가 발생하는 오류 및 상황을 찾기위한 단위 테스트입니다.

단위 테스트 프레임 워크는 예외를 깔끔하게 처리해야합니다. (모든 경우) 대부분의 xUnit의 프레임 워크가 할 수있는 구조가 기대 당신이 테스트중인 시스템에서 특정 예외 조건을 유도하고 예상 예외가 발생하면 테스트 통과를 가지고 있지만 그렇지 않은 경우 실패 할 때 사용하는 특정 예외를.

— mcottle
소스

고급 테스트 프레임 워크는 예외를 매우 잘 처리 할 수 있다고 생각합니다. 심지어 Visual Studio에서는 "예상 예외"라고 말한 것처럼 예외를 테스트 할 수 있습니다. 따라서 알고 공유하는 것이 좋습니다. 감사합니다 ..

— 카스

때때로 좋은 테스트는 테스트가 제대로 이루어지지 않았을뿐 아니라 실패한 경우도 테스트하기 때문에 예외가 발생했는지 확인하려고합니다.

— deadalnix

1

예외가 발생하는 상황 (특히 자신의 예외)을 테스트하려는 경우 예외를 포착하려고합니다. 특정 조건에서 예외로 실패하도록 설계된 코드를 작성하는 경우 해당 조건은 테스트 스위트의 일부이므로 테스트해야합니다. 이러한 테스트에서 이러한 예외를 파악하고 분석해야합니다.

— jwenting

1

읽기에게 두 번째 단락을 @Jwenting - 단위 테스트 프레임 워크는 예외를 포착하고 그렇지 않을 경우 테스트는 특정 예외가 발생하는 경우 통과 실패 할 수

— mcottle

5

(mcottle의 답변과 달리) 긴 대답 : 아니요 ... 대부분의 경우

테스트에서 특정 예외가 발생할 것으로 예상 할 때 해당 테스트의 모든 행이 특정 예외를 발생시키는시기를 알게됩니다.

테스트중인 메소드가 예외를 던진다는 것을 아는 것과는 다릅니다.

테스트에 객체 또는 컨텍스트 설정이 포함 된 경우 (프레임 워크의 버전이 아닌 테스트 내에서 SetUp) 실제로 테스트하려는 단일 행을 시도 / 캐치에서 랩퍼로 래핑하는 것이 좋습니다.

예를 들어

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

그리고

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

이 테스트가 실패하면 테스트중인 메소드가 임의의 설정 항목이 아닌 예외를 던졌습니다.

(임의의 설정 작업을 피하려고 노력해야합니다. 때로는 테스트에 설정 코드를 추가하는 것이 더 쉽습니다.)

— 프랭크 시어
소스

좋은 예입니다! "테스트"단계를 정확한 테스트로 제한하는 데 매우주의를 기울이려고하지만,이를 풀 수있는 방법을 찾을 수없는 경우 (예 : 경쟁 조건 테스트시)에 대한이 트릭을 기억할 것입니다 조건에 도달하려면 '테스트'에 가까운 '설정'이 필요합니다).

— Ethel Evans

1

일반적으로 예외는 제외해야하며 테스트 프레임 워크는 필요한 모든 정보가 포함 된 멋진 보고서를 제공합니다.

그러나 TDD 방법론에서는 다음 단계를 수행해야합니다.

테스트 작성
실패를보고 오류를 이해할 수있게하십시오.
코드 수정
코드와 테스트 리팩토링

예외를 내릴 때 오류가 분명하면 괜찮습니다. 그러나 때로는 예외가 모호하거나 잘못 인도되기도합니다. 어떻게 코드에 넣을 수 있습니까 (나중에 잊어 버렸을 때 또는 문제를 파악하는 데 큰 시간을 허비 할 팀원을 위해)? 따라서 제 정책은 " 실패를 분명히해야하는 경우 예외를 잡아야합니다 "입니다.

— KLE
소스