원문: https://testing.googleblog.com/2008/02/in-movie-amadeus-austrian-emperor.html (Translated by Google Gemini)

영화 아마데우스에서 오스트리아 황제는 모차르트의 음악에 “음표가 너무 많다”고 비판합니다. 하나의 기능을 테스트하는 데 “너무 많은” 테스트는 몇 개일까요?

메서드 decide를 고려해 봅시다.

public void decide(int a, int b, int c, int d, int e, int f) {
  if (a > b || c > d || e > f) {
    DoOneThing();
  } else {
    DoAnother();
  } // 공간 제약 때문에 한 글자 변수 이름을 사용했습니다.
} // 더 나은 이름을 사용해야 합니다. 제가 하는 대로 하지 말고, 제가 시키는 대로 하세요. :-)

얼마나 많은 테스트를 작성할 수 있을까요? 각 변수에 대해 int 값의 전체 범위를 실행하려면 2^192개의 테스트가 필요할 것입니다. 이렇게 계속한다면 구골 개수의 테스트를 하게 될 것입니다! 너무 많은 테스트입니다.

우리가 작성할 수 있는 가장 적은 수의 테스트는 몇 개이며, 여전히 모든 줄이 실행되게 할 수 있을까요? 이것은 100% 라인 커버리지를 달성할 것입니다. 이는 대부분의 코드 커버리지 도구가 측정하는 기준입니다. 두 개의 테스트입니다. 하나는 (a > b || c > d || e > f)가 참인 경우이고, 다른 하나는 거짓인 경우입니다. 대부분의 버그나 코드의 의도하지 않은 변경을 감지하기에는 충분하지 않은 테스트입니다.

논리 표현식과 그 하위 표현식을 테스트하는 데 몇 개의 테스트가 필요할까요? decide의 테스트를 작성할 때 a == b인 경우, 하위 표현식 a > b가 틀렸었고 코드가 a >= b여야 했음을 발견할 수 있습니다. 그리고 a < b 및 a > b인 테스트도 실행하는 것이 합리적일 수 있습니다. 따라서 a를 b와 비교하는 데 세 개의 테스트가 필요합니다. 모든 매개변수에 대해 3 * 3 * 3 = 27개의 테스트가 필요합니다. 이것은 아마 너무 많을 것입니다.

논리 표현식과 그 하위 표현식을 독립적으로 테스트하는 데 몇 개의 테스트가 필요할까요? 논리적 하위 표현식이 추출된 decide의 다른 버전을 고려해 봅시다.

public void decide(int a, int b, int c, int d, int e, f) {
  if (tallerThan(a, b)
      || harderThan(c, d)
      || heavierThan(e, f)) {
    DoOneThing();
  } else {
    DoAnother();
  }
}
boolean tallerThan(int a, b) { return a > b; }
      // "패키지 범위"에 유의하십시오.
boolean harderThan(int c, d) { return c > d; }
      // public이 아닌; JUnit
boolean heavierThan(int e, f) { return e > f; }
      // 테스트는 이들을 접근할 수 있습니다.

우리는 decide에 대해 네 개의 테스트를 작성할 수 있습니다. 하나는 tallerThan이 참인 경우입니다. 하나는 harderThan이 참인 경우입니다. 하나는 heavierThan이 참인 경우입니다. 그리고 하나는 모두 거짓인 경우입니다. 추출된 각 함수를 두 개의 테스트로 테스트할 수 있으므로 총 4 + 2 * 3 = 10개의 테스트가 될 것입니다. 이것은 대부분의 의도하지 않은 변경이 테스트 실패를 유발하기에 충분한 테스트가 될 것입니다. 이러한 방식으로 내부를 노출하는 것은 캡슐화 감소를 테스트 가능성 증가와 교환하는 것입니다. 위 Java 코드에서처럼 적절하게 범위를 제어하여 노출을 제한하십시오.

너무 많은 테스트는 몇 개일까요? 대답은 “경우에 따라 다르다”입니다. 다른 사람들이 변경한 코드에 대해 테스트가 얼마나 많은 신뢰를 제공할 수 있는지에 달려 있습니다. 테스트는 프로그래머가 실수로 코드를 변경했는지 감지할 수 있으며, 예제 및 문서 역할을 할 수 있습니다.

중복 테스트를 작성하지 말고, 너무 적은 테스트도 작성하지 마십시오.