각 단위 테스트는 얼마만큼 테스트해야 합니까?

StackOverflow https://stackoverflow.com/questions/962821

문제

각 단위 테스트에서 얼마나 검사해야 합니까?예를 들어 저는 이런 테스트를 받았습니다.

[TestMethod]
public void IndexReturnsAView()
{
    IActivityRepository repository = GetPopulatedRepository();
    ActivityController activityController = GetActivityController(repository);
    ActionResult result = activityController.Index();
    Assert.IsInstanceOfType(result, typeof(ViewResult));
}

그리고 또한 

[TestMethod]
public void IndexReturnsAViewWithAListOfActivitiesInModelData()
{
    IActivityRepository repository = GetPopulatedRepository();
    ActivityController activityController = GetActivityController(repository);
    ViewResult result = activityController.Index() as ViewResult;
    Assert.IsInstanceOfType(result.ViewData.Model, typeof(List<Activity>));
}

분명히 첫 번째 테스트가 실패하면 두 번째 테스트도 마찬가지이므로 이 두 가지를 두 개의 어설션이 있는 하나의 테스트로 결합해야 합니까?내 생각에는 테스트가 더 세분화되고 각 테스트의 확인 횟수가 적을수록 실패의 원인을 찾는 속도가 더 빨라질 것입니다.그러나 매우 작은 테스트를 엄청나게 많이 수행하면 모든 테스트를 실행하는 데 시간이 걸릴 수 있는 오버헤드가 있습니다.

도움이 되었습니까?

해결책

가능한 한 많이 분해하는 것이 좋습니다.

여기에는 여러 가지 이유가 있습니다. IMHO 가장 중요한 이유는 다음과 같습니다.

  • 언제 테스트 중 하나가 실패하면 가능한 한 빠르고 안전하게 무엇이 잘못되었는지 정확히 찾아낼 수 있기를 원합니다.각 테스트 방법에서 단 하나의 항목만 테스트하는 것이 이를 달성하는 가장 좋은 방법입니다.

  • 각 테스트는 깨끗한 상태에서 시작해야 합니다.리포지토리를 한 번 생성한 다음 2개 이상의 테스트에서 사용하는 경우 해당 테스트 순서에 대한 암시적 종속성이 있습니다.Test1이 저장소에 항목을 추가했지만 삭제하는 것을 잊어버렸다고 가정해 보겠습니다.이제 Test2의 동작이 달라져 테스트가 실패할 수도 있습니다.이에 대한 유일한 예외는 불변 데이터입니다.

속도 문제에 관해서는 걱정하지 않을 것입니다.이와 같은 순수한 코드 처리를 위해 .NET은 매우 빠르고, 당신은 결코 차이를 알 수 없을 것입니다.코드 처리에서 벗어나 데이터베이스와 같은 작업을 시작하자마자 성능 문제를 느끼게 될 것입니다. 그러나 그렇게 하자마자 위에 설명된 대로 모든 "깨끗한 상태" 문제에 직면하게 되므로 그냥 사용하셔도 됩니다. 이를 감수해야 합니다(또는 가능한 한 많은 데이터를 변경할 수 없도록 만들어야 합니다).

테스트에 행운이 있기를 바랍니다.

다른 팁

더 세밀할수록 더 좋습니다. 테스트 사례에서 어설 션이 실패하면 테스트 사례가 더 이상 실행되지 않습니다. 사건의 후자의 부분은 잠재적으로 다른 오류를 발견 할 수 있습니다.

테스트 사례간에 공유 코드가있는 경우 설정/눈물 다운 기능을 사용하여 자신을 너무 많이 반복하지 않고이를 처리하십시오. 시간 비용은 종종 무시할 수 있습니다. 설정/파열에 너무 많은 시간이 걸리면 단위 테스트가 아니라 더 높은 수준의 자동 테스트를 수행 할 수 있습니다. 단위 테스트에는 이상적으로 파일 시스템, 네트워크, 데이터베이스 등의 종속성이 있어야합니다.

"표준"대답은 코드에 버그가 있으면 하나의 테스트를 중단해야하지만 다른 실패를 숨기지 않아야한다는 점에 도달해야한다고 생각합니다 (이 테스트가 실행되는 것을 막지 않음). . 각 테스트는 한 가지 테스트를 테스트하고 두 가지 테스트는 같은 것을 테스트하지 않습니다. 그것은 이상적이며 항상 완성 할 수있는 것은 아닙니다. 안내라고 부릅니다.

즉, 그것은 실제로 예술입니다. 처음에는 성능 문제를 제쳐두고 유지 관리에 더 집중할 것입니다. 거기에는 두 줄의 복제 라인이 있습니다. 디자인이 변경되면 유지하기가 어려워집니다. 중복 자체는이 경우 클래스에 제출 된 설정 방법에 의해 해결 될 수 있지만, 걱정해야 할 것은 유지 보수 가능성입니다.

테스트는 유지 가능하고 이해하기 쉽고, 다른 사람들 (또는 시간이 지나면 합리적)이 코드가 수행하는 작업을 이해하고 테스트를 유지할 수있는 합리적인 것으로 충분히 작아야합니다.

단위 테스트는 기능 설계의 관점에서 기술 설계에 설명 된 내용을 정확하게 테스트해야합니다.

테스트 테스트가 얼마나 많은지에 대한 접근 방식은 분명히 앞서 결정하고 고수해야 할 것입니다. 다른 팀 및/또는 프로젝트가 코딩, 성능, 문제 해결, 테스트 인프라 등에 대한 우선 순위가 다르기 때문에 모든 사람이 동일한 접근 방식을 균일하게 따라야한다고 생각하지 않지만 일관성은 항상 도움이됩니다.

  1. 파기가 얼마나 깊이 있는지 미리 알기 때문에 문제를 더 빨리 식별하십시오.
  2. 테스트를 구성하는 데 시간을 더 적게 보내십시오.
  3. 테스트를 구현하는 동안 동일한 테스트 도우미 클래스를 사용하십시오.
  4. 테스트를 충분히 빨리 실행하십시오 : 너무 빠르지 않고 너무 느리지 않습니다.
  5. 테스트 조직 (스위트, 패키지 등)

성능이 더 중요하다고 결정하면 더 많은 검증/주장으로 더 두꺼운 테스트를 구현하십시오. 문제 해결이 가장 중요하다고 결정하면 필요한만큼 테스트를 분리하십시오. 두껍고 잘 구조화 된 테스트가 왜 결함이 있는지 알 수 없습니다. 이러한 테스트는 더 많은 양의 더 얇은 테스트와 마찬가지로 동일한 작업을 수행합니다.

물론, 모든 테스트는 여전히 특정 기능/기능에 집중해야하지만 실제로이 스레드의 주제는 아닙니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top