[단위 테스트] 02. 단위 테스트란 무엇인가?

요약

• 단위 테스트 정의

  • 단일 동작 단위를 검증하고
  • 빠르게 수행하고
  • 다른 테스트와 별도로 처리한다.

• 격리 문제에 따른 의견 차이

  • 무엇이 단위를 의미하는지에 대한 관점, 테스트 대상 시스템의 의존성 처리 방식에 영향

    • 런던파 : 테스트 대상(클래스)을 서로 분리해야 한다. -> 테스트 대상 이외의 모든 가변 의존성을 테스트 대역으로 대체해야 한다.
    • 고전파 : 단위가 아니라 단위 테스트를 분리해야 한다. 대상 단위는 코드 단위(클래스)가 아니라 동작 단위다. -> 공유 의존성만 테스트 대역으로 대체해야 한다.
• 테스트는 코드 단위가 아니라 동작 단위를 검증해야 한다. 코드 조각을 테스트할 수 없다는 것은 코드 설계에 문제가 있다는 사실을 알려주는 강한 징후이다. 테스트 대역을 사용한다고 해도 이 문제를 해결하는 게 아니라 오히려 숨길 뿐이다.
• 통합 테스트는 단위 테스트 기준 중 하나 이상을 충족하지 못하는 테스트다.

단위 테스트 정의

• 작은 코드 조각을 검증하고,
• 빠르게 수행하고,

• 격리된 방식으로 처리하는 자동화된 테스트

  • 격리 방식에 대한 의견에 따라 런던파와 고전파가 나뉜다.
  • 결국 테스트해야 할 단위의 처리와 의존성 취급에 대한 방법으로 넘어간다.

런던파

• 코드 조각을 격리된 방식으로 검증한다는 것 -> 런던파에서는 테스트 대상 시스템을 협력자에게서 격리하는 것을 말함.

  • 대상이 되는 클래스의 모든 의존성을 테스트 대역으로 대체

• 이점

  • 한 번에 한 클래스만 테스트하기
  • 코드 베이스에서 어디서 문제가 생기는지 바로 알 수 있음.
  • 객체 그래프를 분할할 수 있다.

고전파

• 코드를 꼭 격리하지 않아도 됨. 대신 단위 테스트는 서로 격리해서 실행해야 한다.
• 각각의 테스트를 격리하는 것 = 여러 클래스가 모두 메모리에 상주하고 공유 상태에 도달하지 않는 한, 여러 클래스를 한 번에 테스트해도 괜찮다. -> 공유 의존성이 없는 한 여러 클래스를 묶어서 단위 테스트할 수도 있다.

• 고전파는 단위 테스트간의 격리를 주장 -> 공유 의존성에 대해서만 테스트 대역을 사용.

  • 공유 의존성의 사용은 단위 테스트 간의 간섭을 일으킬 수 있기 때문
  • 공유 의존성의 사용으로 테스트의 실행 속도가 느려지기 때문

• 지금까지 테스트라고 생각했던 거

  • 런던파 입장에서의 테스트 -> 애플리케이션의 동작이 아닌 코드 베이스의 테스트를 작성한 것 같다.

의존성의 종류

• 공유 의존성

  • 테스트 간에 공유되고 서로의 결과에 영향을 미칠 수 있는 수단을 제공하는 의존성
  • 테스트 대상 클래스 간 공유가 아닌 단위 테스트 간의 공유를 의미(?)
  • 예 : http 클라이언트와 같은 공유 객체(싱글턴 패턴으로 만들어진 객체), 데이터 베이스

• 비공개 의존성

  • 테스트 간에 공유되지 않는 의존성
  • 값 객체

• 프로세스 외부 의존성

  • 애플리케이션 실행 프로세스 외부에서 실행되는 의존성
  • 대부분 공유 의존성에 해당하지만 모두 그런것은 아님

• 휘발성 의존성

  • 머신에 기본 설치된 환경 외에 런타임 환경의 설정 및 구성을 요구한다.
  • 예 : 데이터베이사 = 공유 의존성, 휘발성 의존성, 파일 시스템 = 공유 의존성

• 의존성 대체

  • 고전파에서는 공유 의존성을 대역으로 대체한다.
  • 런던파에서는 공유 의존성뿐만 아니라 변경 가능한 의존성도 대역으로 대체할 수 있다.

• 협력자 vs 의존성

  • 협력자 : 공유하거나 변경 가능한 의존성
  • 의존성 : 값 객체

런던파 방식의 이점과 문제점

• 한 번에 한 클래스만 테스트하기

  • 좋은 코드 입자성을 목표로 하는 것은 도움이 되지 않는다.
  • 테스트는 코드의 단위를 검증해서는 안 된다. 오히려 동작의 단위, 즉 문제 역역에 의미가 있는 것, 이상적으로는 비즈니스 담당자가 유용하다고 인식할 수 있는 것을 검증해야 한다.
  • 테스트는 해결하는 데 도움이 되는 문제에 대한 이야기를 들려줘야 하며, 이 이야기는 프로그래머가 아닌 일반 사람들에게 응집도가 높고 의미가 있어야 한다.

• 상호 연결된 클래스의 큰 그래프를 단위 테스트하기

  • 상호 연결된 클래스의 크고 복잡한 그래프를 테스트할 방법을 찾는 대신, 먼저 이러한 클래스 그래프를 갖지 않는데 집중해야 한다. 대게 클래스 그래프가 커진 것은 코드 설계 문제의 결과다.
  • 목을 사용하는 것은 이 문제를 감추기만 할 뿐, 원인을 해결하지 못한다.

• 버그 위치 정확히 찾아내기

  • 고전파에서 여러 클래스를 한 번에 테스트하기 때문에 버그를 찾기 쉽지 않다고 생각할 수 있다.
  • 그러나 마지막으로 한 수정이 무엇인지 알기 때문에 문제를 찾는 것은 그리 어렵지 않다.
  • 버그가 테스트 하나뿐만 아니라 많은 테스트에서 결함으로 이어진다면, 방금 고장 낸 코드 조각이 큰 가치가 있다는 것을 보여준다. 즉 전체 시스템이 그것에 의존한다.

통합 테스트

• 공유 의존성, 프로세스 외부 의존성뿐 아니라 조직 내 다른 팀이 개발한 코드 등과 통합해 작동하는지도 검증하는 테스트

• 런던파의 통합 테스트

  • 실제 협력자 객체를 사용하는 모든 테스트를 통합 테스트로 간주

• 고전파의 통합 테스트

  • 단위 테스트의 기준(단일 동작 단위를 검증하고, 빠르게 수행하고, 다른 테스트와 별도로 처리한다.) 중 하나 이상을 충족하지 않는 테스트
  • 느려진 테스트 : 외부 의존성에 접근하는 테스트
  • 둘 이상의 동작 단위를 검증할 때의 테스트

• 엔트 투 엔드 테스트

  • 통합 테스트의 일부
  • 모든 외부 애플리케이션을 포함해 시스템을 최종 사용자의 관점에서 검증하는 것을 의미
  • 유지 보수 측면에서 가장 비용이 많이 들기 때문에 모든 단위 테스트와 통합 테스트를 통과한 후 빌드 프로세스 후반에 실행하는 것이 좋다.