🐤 Chapter 2: 단위 테스트란 무엇인가

🥕 '단위 테스트'의 정의

단위 테스트는

• 작은 코드 조각을 검증하고,
• 빠르게 수행하고,
• 격리된 방식으로 처리하는 자동화된 테스트다.

대중의 의견이 크게 다른 것은 세 번째 속성이다. 격리 문제는 단위 테스트의 고전파와 런던파를 구분할 수 있게 해주는 근원적 차이에 속한다.

🎈 격리 문제에 대한 런던파의 접근

코드 조각을 격리된 방식을 검증한다는 것은 무엇을 의미하는가? 런던파에서는 테스트 대상 시스템을 협력자에게서 격리하는 것을 일컫는다. 즉, 하나의 클래스가 다른 클래스 또는 여러 클래스에 의존하면 이 모든 의존서을 테스트 대역으로 대체해야 한다. 이런 식으로 동작을 외부 영향과 분리해서 테스트 대상 클래스에만 집중할 수 있다.

의존성이 포함된 테스트 대상 시스템을 검증하는 단위 테스트는 이제 해당 의존성과 별개로 수행할 수 있다. 이 방법의 한 가지 이점은 테스트가 실패하면 코드베이스의 어느 부분이 고장 났는지 확실히 알 수 있다는 것이다. 즉, 확실히 테스트 대상 시스템이 고장 난 것이다. 클래스의 모든 의존성은 테스트 대역으로 대체됐기 때문에 의심할 여지가 없다.

또 다른 이점은 객체 그래프(같은 문제를 해결하는 클래스의 통신망)를 분할할 수 있다는 것이다. 모든 클래스가 각각 직접적인 의존성을 갖고 있으며 또 그 의존성이 또 다른 의존성을 갖고 있는 식으로, 그래프가 상당히 복잡해질 수 있다. 클래스는 심지어 순환 의존성이 있을 수도 있는데, 이는 의존성 사슬이 결국 시작된 위치로 돌아오는 것이다.

의존성을 가진 코드베이스를 테스트하는 것은 테스트 대역 없이는 어렵다. 유일하게 남은 선택은 전체 객체 그래프를 다시 만드는 것이다.

테스트 대역을 사용하면 객체 그래프를 다시 만들지 않아도 된다. 또한 클래스의 직접적인 의존성을 대체할 수 있고, 더 나아가 의존성의 의존성을 다룰 필요도 없다. 그래프를 효과적으로 분해해 단위 테스트에서 준비를 크게 줄일 수 있다.

또한 단위 테스트 격리에는 작지만 유익한 부가적인 이점이 더 있다. 프로젝트 전반적으로 한 번에 한 클래스만 테스트하라는 지침을 도입하면 전체 단위 테스트 스위트를 간단한 구조로 할 수 있다.

예제 책 참고. P.55 ~ P.60

🎈 격리 문제에 대한 고전파의 접근

런던 스타일은 테스트 대역(목)으로 테스트 대상 코드 조각을 분리해서 격리 요구 사항에 다가간다.

고전적인 방법에서 코드를 꼭 격리하는 방식으로 테스트해야 하는 것은 아니다. 대신 단위 테스트는 서로 격리해서 실행해야 한다. 이렇게 하면 테스트를 어떤 순서로든 가장 적합한 방식으로 실행할 수 있으며 서로의 결과에 영향을 미치지 않는다.

각각의 테스트를 격리하는 것은 여러 클래스가 모두 메모리에 상주하고 공유 상태에 도달하지 않는 한, 여러 클래스를 한 번에 테스트해도 괜찮다는 뜻이다. 이를 통해 테스트가 서로 소통하고 실행 컨텍스트에 영향을 줄 수 있다. 데이터베이스, 파일 시스템 등 프로세스 외부 의존성이 이러한 공유 상태의 대표적인 예다.

격리 문제에 대한 이러한 해석에는 목과 기타 테스트 대역을 적당히 쓰려는 견해가 있다. 테스트 대역을 사용할 수 있지만, 보통 테스트 간에 공유 상태를 일으키는 의존성에 대해서만 사용한다.

공유 의존성은 테스트 대상 클래스 간이 아니라 단위 테스트 간에 공유한다. 그런 의미에서 싱글턴 의존성은 각 테스트에서 새 인스턴스를 만들 수 있기만 하면 공유 되지 않는다. 제품 코드에는 싱글턴 인스턴스가 단 하나만 있지만, 테스트는 이 패턴을 따르지 않고 재사용하지도 않는다. 따라서 이러한 의존성은 비공개인 것이다.

공유 의존성을 대체하는 또 다른 이유는 테스트 실행 속도를 높이는 데 있다. 공유 의존성은 거의 항상 실행 프로세스 외부에 있는 데 반해, 비공개 의존성은 보통 그 경계를 넘지 않는다. 그리고 단위 테스트 두 번째 속성으로 빨리 실행해야 하는 필요성이 있으므로, 이러한 호출을 포함하는 공유 의존성을 가진 테스트는 단위 테스트 영역에서 통합 테스트 영역으로 넘어간다.

🥕 단위 테스트의 런던파와 고전파

런던파와 고전파로 나눠진 원인은 격리 특성에 있다. 런던파는 테스트 대상 시스템에서 협력자를 격리하는 것으로 보는 반면, 고전파는 단위 테스트끼리 격리하는 것으로 본다.

종합하면 세 가지 주요 주조에 대해 의견 차이가 있다.

• 격리 요구 사항
• 테스트 대상 코드 조각의 구성 요소
• 의존성 처리

	격리 주체	단위의 크기	테스트 대역 사용 대상
런던파	단위	단일 클래스	불변 의존성 외 모든 의존성
고전파	단위 테스트	단일 클래스 또는 클래스 세트	공유 의존성

🎈 고전파와 런던파가 의존성을 다루는 방법

테스트 대역은 어디에서나 흔히 사용할 수 있지만, 런던파는 테스트에서 일부 의존성을 그대로 사용할 수 있도록 하고 있다. 여기서 리트머스 시험은 의존성의 변경 가능 여부다. 절대 변하지 않는 객체, 즉 불변 객체는 교체하지 않아도 된다.

의존성은 공유되거나 비공개일 수 있다. 다시 비공개 의존성은 변경 가능하거나 불변일 수 있다. 불변인 경우 값 객체라고 부른다. 예를 들어 데이터베이스는 공유 의존성이며, 내부 상태는 (테스트 대역으로 대체되지 않은) 모든 자동화된 테스트에서 공유한다. 모든 공유 의존성은 변경 가능하지만, 변경 가능한 의존성을 공유하려면 여러 테스트에서 재사용돼야 한다.

모든 프로세스 외부 의존성이 공유 의존성의 범주에 속하는 것은 아니다. 공유 의존성은 거의 항상 프로세스 외부에 있지만, 그 반대는 그렇지 않다. 프로세스 외부 의존성을 공유하려면 단위 테스트가 서로 통신할 수 있는 수단이 있어야 한다. 의존성 내부 상태를 수정하면 통신이 이뤄진다. 그런 의미에서 프로세스 외부의 불변 의존성은 그런 수단을 제공하지 않는다. 테스트는 내부의 어떤 것도 수정할 수 없기 때문에 서로 실행 컨텍스트에 영향을 줄 수 없다.

🥕 고전파와 런던파의 비교

고전파와 런던파 간의 주요 차이는 단위 테스트의 정의에서 격리 문제를 어떻게 다루는지에 있다. 이는 결국 테스트해야 할 단위의 처리와 의존성 취급에 대한 방법으로 넘어간다.

개인적으로는 단위 테스트 고전파를 선호한다. 이는 고품질의 테스트를 만들고 단위 테스트의 궁극적인 목표인 프로젝트의 지속 가능한 성장을 달성하는 데 더 적합하다. 그 이유는 취약성(fragility)에 있다. 목을 사용하는 테스트는 고전적인 테스트보다 불안정한 경향이 있기 때문이다. 지금은 런던파의 주요 장점을 하나씩 살펴보자.
런던파의 접근 방법은 다음과 같은 이점을 제공한다.

• 입자성이 좋다. 텐스트가 세밀해서 한 번에 한 클래스만 확인한다.
• 서로 연결된 클래스의 그래프가 커져도 테스트하기 쉽다. 모든 협력자는 테스트 대역으로 대체되기 때문에 테스트 작성 시 걱정할 필요가 없다.
• 테스트가 실패하면 어떤 기능이 실패했는지 확실히 알 수 있다. 클래스의 협력자가 없으면 테스트 대상 클래스 외에 다른 것을 의심할 여지가 없다.

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

런던파는 클래스를 단위로 간주한다. 객체지향 프로그래밍 경력을 가진 개발자들은 보통 클래스를 모든 코드베이스의 기ㅈ초에 위치한 원자 빌딩 블록으로 간주한다. 이로 인해 자연스럽게 클래스를 테스트에서 검증할 원자 단위로도 취급하게 한다.
그래서 좋은 코드 입자성을 목표로 하는 것은 도움이 되지 않는다. 테스트가 단일 동작 단위를 검증하는 한 좋은 테스트다. 이보다 적은 것을 목표로 삼는다면 사실 단위 테스트를 훼손하는 결과를 가져온다. 이 테스트가 무엇을 검증하는지 정확히 이해하기가 더 어려워지기 때문이다. 테스트는 해결하는 데 도움이 되는 문제에 대한 이야기를 들려줘야 하며, 이 이야기는 프로그래머가 아닌 일반 사람들에게 응집도가 높고 의미가 있어야 한다.

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

실제 협력자를 대신해 목을 사용하면 클래스를 쉽게 테스트할 수 있다. 특히 테스트 대상 클래스에 의존성이 있고, 이 의존성에 다시 각각의 의존성이 있고, 이렇게 여러 계층에 걸쳐서 계속되는 식으로 의존성 그래프가 복잡하게 있을 때 쉽게 테스트할 수 있다.

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

테스트에서 이 문제를 지적한 것은 사실 좋은 일이다. 즉, 비교적 높은 정확도로 저품질을 예측한다. 클래스를 단위 테스트하려면 테스트 준비 단계를 적정선을 넘게 늘려야 해서 이는 틀림없이 문제의 징후가 있다. 목을 사용하는 것은 이 문제를 감추기만 할 뿐, 원인을 해결하지 못한다.

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

런던 스타일 테스트가 있는 시스템에 버그가 생기면, 보통 SUT에 버그가 포함된 테스트만 실패한다. 하지만 고전적인 방식이면, 오작동하는 클래스를 참조하는 클라이언트를 대상으로 하는 테스트도 실패할 수 있다. 즉, 하나의 버그가 전체 시스템에 걸쳐 테스트 실패를 예기하는 파급 효과를 초래한다. 결국 문제의 원인을 찾기가 더 어려워진다.

우려할 만하지만, 큰 문제는 아니다. 테스트를 정기적으로 실행하면 버그의 원인을 알아낼 수 있다. 즉, 마지막으로 한 수정이 무엇인지 알기 때문에 문제를 찾는 것은 그리 어렵지 않다. 또한 실패한 테스트를 모두 볼 필요는 없다. 하나를 고치면 다른 것들도 자동으로 고쳐진다.

계다가 테스트 스위트 전체에 걸쳐 계단식으로 실패하는 데 가치가 있다. 버그가 테스트 하나뿐만 아니라 많은 테스트에서 결함으로 이어진다면, 방금 고장 낸 코드 조각이 큰 가치가 있다는 것을 보여준다. 즉, 전체 시스템이 그것에 의존한다. 인 코드 작업 시 명심해야 할 유용한 정보다.

🎈 고전파와 런던파 사이의 다른 차이점

고전파와 런던파 사이의 남아있는 두 가지 차이점은 다음과 같다.

• 테스트 주도 개발(TDD)을 통한 시스템 설계 방식
• 과도한 명세 문제

런던 스타일의 단위 테스트는 하향식 TDD로 이어지며, 전체 시스템에 대한 기대치를 설정하는 상위 레벨 테스트부터 시작한다. 목을 사용해 예상 결과를 달성하고자 시스템이 통신해야 하는 협력자를 지정한다. 그런 다음 모든 클래스를 구현할 때까지 클래스 그래프를 다져나간다. 목은 한 번에 한 클래스에 집중할 수 있기 때문에 이 설계 프로세스를 가능하게 한다.

고전파는 테스트에서 실제 객체를 다뤄야 하기 때문에 지침을 똑같이 두지 않는다. 대신 일반적으로 상향식으로 한다. 고전적 스타일에서는 도메인 모델을 시작으로 최종 사용자가 소프트웨어를 사용할 수 있을 때까지 계층을 그 위에 더 둔다.

그러나 고전파와 런던파 간의 가장 중요한 차이점은 과도한 명세 문제, 즉 테스트가 SUT의 구현 세부 사항에 결합되는 것이다. 런던 스타일은 고전 스타일보다 테스트가 구현에 더 자주 결합되는 편이다. 이로 인해 런던 스타일과 목을 전반적으로 아무 데나 쓰는 것에 대해 주로 이의가 제기된다.

🥕 두 분파의 통합 테스트

런던파는 실제 협력자 객체를 사용하는 모든 테스트를 통합 테스트로 간주한다. 고전 스타일로 작성된 대부분의 테스트는 런던파 지지자들에게 통합 테스트로 느껴질 것이다.

이 책에서는 단위 테스트와 통합 테스트의 고전적인 정의를 사용한다. 다시 말하지만, 단위 테스트는 다음과 같은 특징이 있는 자동화된 테스트다.

• 작은 코드 조각을 검증하고
• 빠르게 수행하고
• 격리된 방식으로 처리한다.

첫 번째 속성과 세 번째 속성의 의미를 명확히 밝혔으니 고전파의 관점에서 다시 정의해본다. 단위 테스트는

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

통합 테스트는 이러한 기준 중 하나를 충종하지 않는 테스트다. 예를 들어 공유 의존성(말하자면, 데이터베이스)에 접근하는 테스트는 다른 테스트와 분리해 실행할 수 없다. 어떤 테스트에서 데이터베이스 상태 변경이 생기면 병렬로 실행할 때 동일한 데이터베이스에 의존하는 다른 모든 테스트의 결과가 변경될 것이다.

마찬가지로 프로세스 외부 의존성에 접근하면 테스트가 느려진다. 데이터베이스에 대한 호출은 실행 시간에 수백 밀리초를 추가한다. 처음에는 밀리초가 미미해 보일 수 있지만, 테스트 스위트가 충분히 커지면 1초가 중요하다.

마지막으로, 둘 이상의 동작 단위를 검증할 때의 테스트는 통합 테스트다. 이는 종종 테스트 스위트의 실행 속도를 최적화하려는 노력의 결과다. 비슷한 단계를 따르지만 다른 동작 단위를 검증하는 느린 테스트가 두 개 있을 때, 하나로 합치는 것이 타당할 수 있다. 즉, 비슷한 두 동작을 검증하는 하나의 테스트이지만 세밀한 테스트 두 개보다 빠르게 실행할 수 있다.
또한 다른 팀이 개발한 모듈이 둘 이상 있을 때 통합 테스트로 어떻게 작동하는지 검증할 수 있다. 이는 또한 여러 동작 단위를 한 번에 검증하는 제3의 테스트 유형에 해당한다. 그러나 다시 말하지만, 이러한 통합은 통상적으로 프로세스 외부 의존성을 필요로 하므로 테스트는 하나뿐만 아니라 세 가지 기준 모두를 충적하지 못할 것이다.

🎈 통합 테스트의 일부인 엔드 투 엔드 테스트

간단히 말해 통합 테스트는 공유 의존성, 프로세스 외부 의존성뿐 아니라 조직 내 다른 팀이 개발한 코드 등과 통합해 작동하는지도 검증하는 테스트다. 엔드 투 엔드 테스트라는 개념도 따로 있다. 엔드 투 엔드 테스트는 통하 테스트의 일부다 엔드 투 엔드 테스트도 코드가 프로세스 외부 종속성과 함께 어떻게 작동하는지 검증한다. 엔드 투 엔드 테스트와 통합 테스트 간의 차이점은 엔드 투 엔트 테스트가 일반적으로 의존성을 더 많이 포함한다는 것이다.

가끔은 경계가 흐리지만, 일반적으로 통합 테스트는 프로세스 외부 의존성을 한둑 개만 갖고 작동한다. 반면에 엔드 투 엔드 테스트는 프로세스 외부 의존성을 전부 또는 대다수 갖고 작동한다. 따라서 엔드 투 엔드라는 명칭은 모든 외부 애플리케이션을 포함해 시스템을 최종 사용자의 관점에서 검증하는 것을 의미한다.
또한 UI 테스트, GUI 테스트, 기능 테스트와 같은 용어도 사용한다. 용어들이 잘 정의돼 있지 않지만, 일반적으로 모두 동의어다.

애플리케이션이 데이터베이스, 파일 시스템, 결제 게이트웨이라는 세 가지 프로세스 외부 의존성으로 작동한다고 가정하자. 일반적인 통합 테스트는 데이터베이스와 파일 시스템은 완전히 제어할 수 있기 때문에 테스트에서 필요한 상태로 쉽게 가져올 수 있는 반면, 결제 게이트웨이의 제어 권한은 그렇지 않다. 또한 과저 테스트 실행에서 남긴 모든 결제 비용을 수동으로 정리하고자 때때로 해당 계정을 확인해야 할 수도 있다.

엔드 투 엔드 테스트는 유지 보수 측면에서 가장 비용이 많이 들기 때문에 모든 단위 테스트와 통합 테스트를 통과한 후 빌드 프로세스 후반에 실행하는 것이 좋다. 또한 개인 개발자 머신이 아닌 빌드 서버에서만 실행할 수도 있다.

엔드 투 엔드 테스트를 하더라도 모든 프로세스 외부 의존성을 처리하지 못할 수도 있다. 일부 의존성의 테스트 버전이 없거나 해당 의존성을 필요한 상태로 자동으로 가져오는 것이 불가능할 수 있다. 따라서 여전히 테스트 대역을 사용할 필요가 있고, 통합 테스트와 엔드 투 엔드 테스트 사이에 뚜렷한 경계가 없다는 사실을 강조한다.