Java Language
단위 테스트

소개

비고

단위 테스트 란 무엇입니까?

이것은 약간의 입문서입니다. 스텁 아티클로 의도 된 경우에도 문서가 강제로 예제로 사용되기 때문에 대부분 넣습니다. 단위 테스트의 기초를 이미 알고 있다면 구체적인 프레임 워크가 언급 된 발언으로 건너 뛸 수 있습니다.

단위 테스트는 주어진 모듈이 예상대로 작동하는지 확인하는 것입니다. 대규모 응용 프로그램에서 진공 상태에서 모듈을 적절하게 실행하는 것은 응용 프로그램 충실도 보장의 핵심 요소입니다.

다음 (사소한) 의사 - 예를 고려하십시오.

public class Example {
  public static void main (String args[]) {
    new Example();
  }

  // Application-level test.
  public Example() {
    Consumer c = new Consumer();
    System.out.println("VALUE = " + c.getVal());
  }

  // Your Module.
  class Consumer {
    private Capitalizer c;
  
    public Consumer() {
      c = new Capitalizer();
    }

    public String getVal() {
      return c.getVal();
    }
  }

  // Another team's module.
  class Capitalizer {
    private DataReader dr;
  
    public Capitalizer() {
      dr = new DataReader();
    }

    public String getVal() {
      return dr.readVal().toUpperCase();
    }
  }

  // Another team's module.
  class DataReader {
    public String readVal() {
      // Refers to a file somewhere in your application deployment, or
      // perhaps retrieved over a deployment-specific network.
      File f; 
      String s = "data";
      // ... Read data from f into s ...
      return s;
    }
  }
}

따라서이 예는 간단합니다. DataReader 는 파일에서 데이터를 가져 와서 모든 문자를 대문자로 변환 한 Capitalizer 에 전달한 다음 Consumer 전달합니다. 그러나 DataReader 는 응용 프로그램 환경과 밀접하게 연결되어 있으므로 테스트 릴리스를 배포 할 준비가 될 때까지이 체인의 테스트를 연기합니다.

이제 알 수없는 이유로 릴리스에서 어딘가에있는 getVal() Capitalizer 의 getVal() 메서드가 toUpperCase() 문자열을 toLowerCase() 문자열로 반환하는 것으로 변경되었습니다.

  // Another team's module.
  class Capitalizer {
    ...

    public String getVal() {
      return dr.readVal().toLowerCase();
    }
  }

분명히 이것은 예상되는 동작을 중단시킵니다. 그러나 DataReader 실행과 관련된 까다로운 프로세스로 인해 다음 테스트 배포가 완료 될 때까지이 사실을 알 수 없습니다. 따라서 시스템에이 버그가있는 데 일 / 주 / 월이 지나면 제품 관리자가이를보고 Consumer 와 관련된 팀 리더에게 즉시 응답합니다. "왜 이런 일이 일어난거야? 너희들은 무엇을 바꿨 니?" 분명히, 당신은 우둔 해. 무슨 일이 벌어지고 있는지 전혀 모른다. 이 코드를 수정해야하는 코드는 변경하지 않았습니다. 왜 갑자기 깨진거야?

결국 팀과 협업을 논의한 후에 문제가 추적되고 문제가 해결됩니다. 그러나, 그것은 질문을 구걸한다. 어떻게 이것이 막을 수 있었습니까?

두 가지 분명한 사실이 있습니다.

테스트를 자동화해야합니다.

수동 테스트에 대한 우리의 의존은이 버그가 너무 오랫동안 주목받지 못하게했습니다. 버그가 즉시 도입되는 프로세스를 자동화하는 방법이 필요합니다. 지금부터 5 주가 아니야. 5 일 후가 아닙니다. 지금부터 5 분이 안 남았습니다. 지금.

이 예에서 소개되고 알려지지 않은 아주 사소한 버그를 표현했습니다. 수십 개의 모듈이 지속적으로 업데이트되는 산업 응용 프로그램에서는 이러한 모든 것들이 그 자리에 들어올 수 있습니다. 하나의 모듈로 무언가를 고쳐서, 고정 된 행동이 다른 방법 (내부적으로나 외부 적으로)에 의존한다는 것을 깨닫기 만하면됩니다.

엄격한 검증 없이는 시스템에 문제가 생길 것입니다. 충분히 무시한 채로하면 변경 사항을 수정하고 수정 사항을 수정하는 등 많은 노력을 기울일 수 있으며, 노력이 투입 될 때 제품이 실제로 남아있는 작업이 늘어날 수 있습니다. 너는이 상황에 있고 싶지 않아.

테스트는 세분화되어야합니다.

위 예제에서 언급 한 두 번째 문제점은 버그를 추적하는 데 걸린 시간입니다. 제품 관리자가 테스터가 알아 차렸을 때 핑 (ping)하여 Capitalizer 가 겉으로보기에는 나쁜 데이터를 반환하고 Capitalizer 팀에 조사 결과를 핑 분석하고 조사한 사실 등을 조사하고 발견했습니다.

이 간단한 예제의 양과 난이도에 관해 위에서 설명한 것과 같은 점을 여기서 확인하십시오. 분명히 Java를 합리적으로 잘 알고있는 사람이라면 도입 된 문제를 빨리 발견 할 수 있습니다. 그러나 종종 문제를 추적하고 전달하는 것이 훨씬 더 어렵습니다. 어쩌면 Capitalizer 팀이 소스가없는 JAR을 제공했을 수도 있습니다. 어쩌면 그들은 세계의 다른쪽에 위치 할 수 있으며 통신 시간은 매우 제한적입니다 (아마도 하루에 한 번 발송되는 전자 우편까지). 버그를 추적하는 데 몇 주 또는 그 이상의 시간이 걸릴 수 있습니다 (주어진 릴리스에 대해 여러 가지가있을 수 있습니다).

이을 완화하기 위해, 우리는 가능한 한 미세한 수준 (당신은 또한 모듈이 올바르게 상호 작용을 보장하기 위해 대단위 테스트를 원하는,하지만 여기에 우리의 초점이 아니다)에 대한 엄격한 테스트를합니다. 우리는 외부 지향적 인 모든 기능 (최소한)이 어떻게 작동 하는지를 엄격하게 지정하고 해당 기능을 테스트하려고합니다.

단위 테스트 입력

특히 Capitalizer 의 getVal() 메서드가 주어진 입력 문자열에 Capitalizer 로 된 문자열을 반환 getVal() 확인하는 테스트가 있다고 상상해보십시오. 게다가 우리가 코드를 작성하기 전에 테스트가 실행되었다고 상상해보십시오. 시스템에 도입 버그 (즉, toUpperCase() 로 대체되고 toLowerCase() 버그가 시스템에 도입되지 않을 것이기 때문에) 어떤 문제를 일으킬 수 없을 것입니다. 우리는 테스트에서 그것을 잡을 것이고, 개발자는 실수로 실수를 깨닫게 될 것이고, 의도 된 효과를 어떻게 이끌어 낼지에 대한 대안적인 해결책이 될 것입니다.

여기에는 이러한 테스트를 구현 하는 방법에 대한 몇 가지 생략이 있지만 프레임 워크 관련 문서 (설명에 링크되어 있음)에서 다룹니다. 바라건대, 이것은 단위 테스트가 중요한 이유 의 예입니다.