그것은.

단위 테스트 만 수행하더라도 실제로 테스트 된 코드보다 더 많은 코드를 테스트에 포함시키는 것은 드문 일이 아닙니다. 아무 문제가 없습니다.

간단한 코드를 고려하십시오.

public void SayHello(string personName)
{
    if (personName == null) throw new NullArgumentException("personName");

    Console.WriteLine("Hello, {0}!", personName);
}

시험은 무엇입니까? 테스트 할 간단한 경우가 4 가지 이상 있습니다.

1. 사람 이름은 null입니다. 실제로 예외가 발생합니까? 그것은 적어도 세 줄의 테스트 코드입니다.

2. 사람 이름은 "Jeff"입니다. 우리 "Hello, Jeff!"는 응답을 받습니까? 그것은 네 줄의 테스트 코드입니다.

3. 사람 이름은 빈 문자열입니다. 우리는 어떤 결과를 기대합니까? 실제 출력은 무엇입니까? 부수적 인 질문 : 기능 요구 사항과 일치합니까? 이는 단위 테스트를위한 또 다른 4 줄의 코드를 의미합니다.

4. 사람 이름은 문자열에 비해 짧지 만 "Hello, "느낌표와 결합하기에는 너무 깁니다 . 어떻게 되나요? ¹

이를 위해서는 많은 테스트 코드가 필요합니다. 또한 가장 기본적인 코드 조각에는 테스트중인 코드에 필요한 객체를 초기화하는 설정 코드가 필요한 경우가 많으며, 종종 스텁 및 모의 작성 등으로 이어집니다.

비율이 매우 큰 경우 몇 가지 사항을 확인할 수 있습니다.

• 테스트 전체에 코드 중복이 있습니까? 테스트 코드라는 사실이 유사한 테스트간에 코드를 복제 (복사 붙여 넣기)해야한다는 의미는 아닙니다. 이러한 복제로 인해 테스트 유지 관리가 어려워집니다.

• 중복 테스트가 있습니까? 일반적으로 단위 테스트를 제거하면 분기 범위가 줄어 듭니다. 그렇지 않은 경우 경로가 이미 다른 테스트에 포함되어 있으므로 테스트가 필요하지 않음을 나타낼 수 있습니다.

• 테스트해야 할 코드 만 테스트하고 있습니까? 타사 라이브러리 의 기본 프레임 워크 를 테스트 할 필요는 없으며 프로젝트 코드 만 독점적 으로 테스트해야 합니다.

연기 테스트, 시스템 및 통합 테스트, 기능 및 승인 테스트 및 스트레스 및로드 테스트를 사용하면 더 많은 테스트 코드를 추가 할 수 있으므로 실제 코드의 모든 LOC에 대해 4-5 개의 LOC 테스트를 갖는 것은 걱정할만한 것이 아닙니다.

TDD에 대한 메모

코드를 테스트하는 데 걸리는 시간이 걱정된다면 코드를 잘못 작성했을 수 있습니다. 이 경우 TDD는 코드와 테스트간에 전환하여 15-45 초의 반복 작업을 장려함으로써 도움이 될 수 있습니다. TDD의 지지자에 따르면 필요한 테스트 수와 더 중요하게는 테스트를 위해 작성하고 특히 다시 작성 해야하는 비즈니스 코드의 양을 줄임으로써 개발 프로세스 속도를 높 입니다.

^{하자 ¹ N 될 문자열의 최대 길이 . SayHello길이 n -1 의 문자열을 참조로 호출 하고 전달할 수 있습니다. 이 문자열은 정상적으로 작동합니다. 이제 Console.WriteLine단계에서 형식화는 길이가 n + 8 인 문자열로 끝나므로 예외가 발생합니다. 아마도 메모리 제한으로 인해 n / 2 문자를 포함하는 문자열조차도 예외가 발생할 수 있습니다. 질문해야 할 질문은이 네 번째 테스트가 하나의 단위 테스트인지 (하나는 비슷하지만 평균 단위 테스트에 비해 리소스 측면에서 훨씬 더 큰 영향을 줄 수 있음) 실제 코드 또는 기본 프레임 워크를 테스트하는지 여부입니다.}

답변