2. 단위테스트

단위 테스트를 읽고 학습한 내용을 정리한 글입니다. 학습 과정에서 작성되었기 때문에 잘못된 내용이 있을 수 있습니다. 

 

 

 

 

1. 단위 테스트

---

단일 동작 단위를 검증하고 빠르게 수행되며, 다른 테스트와 별도로 처리하는 테스트를 말합니다. 하나의 클래스가 다른 클래스 또는 여러 클래스에 의존하면 이 모든 의존성을 테스트 대역(test double)로 대체하며, 동작을 외부 영향과 분리해서 테스트 대상 클래스에만 집중할 수 있게 합니다. 단, 단위가 반드시 클래스로 국한될 필요는 없는데, 공유 의존성이 없는 한 여러 클래스를 묶어서 단위테스트를 할 수도 있기 때문입니다. **작은 코드 조각이란 한 행위(메서드)에 대한 검증일 수도 있고, 클래스에 대한 테스트일 수도 있습니다.

 

    - 작은 코드 조각(단위) 검증

    - 빠른 수행

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

 

 

 

 

 

이를 통해 크게 두 가지 이점을 얻을 수 있는데, 첫 번째로 테스트가 실패하면 코드베이스의 어느 부분이 고장 났는지 확실히 알 수 있습니다. 하나의 테스트 대상을 테스트 대역으로 구분하기 때문에 명확한 실패 원인을 알 수 는 것입니다. 이를통해 단위 테스트와 실제 코드를 1:1로 대응시켜 테스트를 더욱 세밀하게 할 수 있습니다. 

 

 

 

 

 

 

두 번째 장점은 객체 그래프를 분할할 수 있는 것입니다. 모든 클래스가 각각 직접적 의존성을 가지고 있으면, 또한 그 의존성이 다른 의존성을 가지고 있으면 그래프가 복잡해집니다. 이는 순환 의존성일 수도 있으며, 결국시작된 위치로 돌아올 수도 있어 테스트를 정확하게 할 수 없습니다. 이때 테스트 대역을 사용하면 클래스의 직접적 의존성을 대체할 수 있고 심지어 의존성의 의존성을 다룰 필요도 없습니다. 

 

 

 

 

 

 

 

즉, 객체를 효과적으로 분해해서 단위 테스트 준비 비용을 낮출 수 있는 것입니다. 대역을 쓰면 클래스의 직접적인 의존성을 대체해 그래프를 나눌 수 있으며, 이는 단위테스트에서 준비해야 할 작업량을 크게 줄일 수 있습니다. 물론 상호 연결된 클래스의 크고 복잡한 그래프를 테스트할 방법을 찾는 대신 먼저 이러한 클래스 그래프를 갖지 않는데 집중해야 하는데, 대개 클래스 그래프가 커진 것은 곧 설계 문제이기 때문입니다. 테스트 대역을 나누기 위해서는 SUT를 사용해야 하며, SUT에는 아래와 같은 연관 개념/용어들이 존재합니다. * MUT와 SUT는 동의어로 사용되지만 일반적으로 MUT는 메서드를 가리키는 데 반해 SUT는 클래스 전체를 가리킵니다.

 

SUT	테스트 대상 시스템(SUT, System Under Test)
MUT	테스트에서 호출한 SUT의 메서드.
테스트 대역	실행과 관련 없이 모든 종류의 가짜 의존성을 설명하는 포괄적 용어
목	테스트 대상 시스템과 협력자 간의 상호 작용을 검사할 수 있는 특별한 테스트 대역      **테스트 대역의 한 종류

 

 

 

 

 

 

2. 의존성에 관한 개념/용어

---

공유 의존성은 테스트 대상 클래스 간이 아니라 테스트 간에도 공유 됩니다. 특히 싱글톤에서 많이 나타나는데, 그러나 설사 싱글톤으로 만들더라도  이를 매번 새로 생성해서 비공개 의존성을 유지할 수도 있습니다. 예를 들어 설정 클래스는 일반적으로 한 개 뿐이지만 모든 의존성이 SUT에 주입되면 각 테스트에서 새 인스턴스를 만들 수 있으므로 테스트 전체에서 단일 인스턴스를 유지할 필요가 없습니다. *반면 파일 시스템이나 데이터베이스는 만들 수 없기 때문에 테스트 간 공유되거나 테스트 대역으로 대체 돼야 합니다. 

 

공유 의존성	테스트 간에 공유되고 결과에 영향을 미칠 수 있는 수단을 제공하는 의존성     ex) 정적 가변 필드, 데이터 베이스
비공개 의존성	공유하지 않는 의존성
프로세스 외부 의존성	애플리케이션 실행 프로세스 외부에서 실행되는 의존성. 이는 대부분 공유       의존성이지만 모두 그렇지는 않다.

* 단위 테스트를 격리하는 것은 테스트 대상 클래스에서 공유 의존성만 격리하는 것을 의미한다. 비공개 의존성은 그대로 둔다.

 

 

 

 

 

 

프로세스 외부 의존성이란 아직 메모리에 없는 데이터, 즉 프록시(proxy)에 대한 의존성을 이야기하는데, 이는 대부분 공유 의존성이지만 모두 그렇지는 않습니다. 예를 들어 데이터베이스는 프로세스 외부이면서 공유 의존성입니다. 그러나 각 테스트 실행 전 도커 컨테이너로 데이터베이스를 시작하면 테스트가 더 이상 동일한 인스턴스로 작동하지 않기 때문에 프로세스 외부이면서 공유하지 않는 의존성이 됩니다. 이는 테스트가 데이터를 변경할 수 없으므로, 즉 모든 테스트마다 별개로 동작하게 되므로 각 테스트의 결과가 다른 테스트에 영향을 미칠 수 없습니다. 

 

 

이런 공유 의존성은 테스트 간 대체되는데, 이는 테스트 실행 속도를 높이는 데 있습니다. 공유 의존성은 거의 실행 프로세스 외부에 있는 데 반해, 비공개 의존성은 보통 그 경계를 넘지 않기 때문입니다. 따라서 데이터베이스나 파일 시스템 등의 공유 의존성에 대한 호출은 비공개 의존성에 대한 호출보다 더 오래 걸립니다. 그리고 이러한 호출을 포함하는 공유 의존성을 가진 테스트는 단위 테스트 영역에서 통합 테스트 영역으로 넘어갑니다.

 

 

휘발성 의존성은 런타임 환경의 설정 및 구성을 요구하거나 비결정적 동작을 포함합니다. 즉, 추가 설정이 필요하거나 각 호출에 대해 다른 결과를 제공하는 것을 포함합니다. 공유 의존성과 휘발성 의존성은 겹치는 부분이 존재하기도 하는데, 예를들어 아래 그림에서 데이터베이스는 공유 의존성이자 휘발성 의존성입니다. 반면 파일 시스템은 단위 테스트가 실행 컨텍스트를 방해할 수 있기 때문에 공유 의존성이지만 휘발성 의존성은 아닙니다. 즉, 단위테스트가 파일 시스템의 내용을 바꾸어 다음 테스트의 결과를 방해할 수도 있는 것을 말합니다. **난수 생성기는 휘발성 의존성이지만 별도의 인스턴스를 제공할 수 있기 때문에 공유 의존성은 아닙니다.

 

 

 

 

 

휘발성 의존성이란?

휘발성 의존성이란 개발자 머신에 기본 설치된 환경 외에 런타임 환경의 설정 및 구성을 요구하거나 비결정적 동작(nondeterministic behavior) 중 하나가 포함된 것을 말합니다. 예를들어 데이터베이스와 API 서비스가 있습니다. 비결정적 동작(nondeterministic behavior)이란 난수 생성기와 같이 각 호출에 대해 다른 결과를 제공하기 때문에 비결정적이라고 합니다. 단, 이 또한 목으로 대체를 해서 결정적 동작으로 만들 수 있습니다. 

 

 

 

 

 

 

3. 런던 파 / 고전 파

---

런던 스타일은 테스트 대역(목)으로 테스트 대상 코드 조각을 분리해서 격리 요구 사항에 다가갑니다. 이때 각각의 모든 클래스를 격리해야 한다면 테스트 대상 코드 조각은 단일 클래스거나 해당 클래스 내의 메서드입니다. 반면 고전파는 단위 테스트는 서로 격리돼서 실행합니다. 어떤 순서로든 가장 적합한 방식으로 실행할 수 있으며 서로의 결과에 영향을 미치지 않습니다.

 

 

이 둘은 격리 특성에 의해 나눠지게 되었는데, 런던파는 테스트 대상 시스템에서 협력자를 격리하는 것으로 보는 반면 고전파는 단위 테스트끼리 격리하는 것으로 봅니다. 이는 결국 테스트해야 할 단위의 처리와 의존성 취급에 대한 방법으로 넘어가는데, 즉  세 가지 주요 주제에 대해 의견 차이가 있습니다. 

 

     - 격리 요구 사항

     - 테스트 대상 코드 조각(단위)의 구성 요소

     - 의존성 처리

 

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

 **각각의 테스트를 격리하는 것은 여러 클래스가 모두 메모리에 상주하고 공유 상태에 도달하지 않는 한 여러 클래스를 한 번에 테스트해도 괜찮다는 뜻입니다. 이를 통해 테스트가 서로 소통하고 실행 컨텍스트에 영향을 줄 수 있습니다. 

 

 

 

 

 

 

이 둘은 의존성을 다루는 방법에도 차이가 있었는데 런던파는 테스트에서 일부 의존성을 그대로 사용할 수 있도록 하고 있다. 즉, 변하지 않는 객체 , 즉 불변 객체라면 이를 굳이 교체하지 않아도 된다. 이런 불변 객체를 값 객체(value object) 또는 값(value)라고 한다. 중 특징은 각가의 정체성이 없다는 것이다. 즉, 내용에 의해서만 식별된다. 그 결과 두 객체가 동일한 내용을 가지고 있다면 어떤 객체를사용해도 된다. 이러한 인스턴스는 서로 바꿔 사용할 수 있다. 

 

이 둘은 테스트 코드를 작성하는 방법에도 차이가 있는데 런던 스타일은 하향식 TDD를, 고전파는 상향식 TDD를 지향한다. 런던 스타일은 목 객체를 통해 상위 레벨에서부터 테스트를 해가며 한 번에 한 클래스에 집중할 수 있게 한다. 이를 통해 모든 협력자를 차단해 해당 협력자의 구현을 나중으로 미룰 수 있다.

 

반면 고전파는 실제 객체를 다뤄야 하므로 지침을 똑같이 두진 않는다. 도메인 모델을 시작으로 최종 사용자가 소프트웨어를 사용할 수 있을 때까지 계층을 그 위에 더 둔다. 런던 스타일은 고전 스타일보다 테스트가 구현에 더 자주 결합하며, 목 객체를 전반적으로 너무 남용하는 것에 대한 문제가 제기된다.

 

 

 

 

 

 

 

 

협력자 대 의존성

협력자는 공유하거나 변경 가능한 의존성입니다. 예를 들어 데이터베이스는 공유 의존성이므로 데이터베이스 접근 권한을 제공하는 클래스는 협력자가 되며,  또한 시간에 따라 상태가 변할 수도 있습니다. 일반적인 클래스는 두 가지 유형의 의존성으로 동작하는데 협력자와 값입니다. 예를들어 아래의 경우 세 가지 의존성이 존재하는데, store는 협력자이며, 나머지 둘(Product, 5)은 아닙니다. 

 

customer.purchage(store, Product.Shampoo, 5);

 

 

 

 

 

모든 프로세스 외부 의존성이 공유 의존성의 범주에 속하진 않습니다. 프로세스 외부 의존성을 공유하려면 단위 테스트가 서로 통신할 수 있는 수단이 있어야 합니다. 이는 의존성 내부 상태를 수정하면 발생하는데, 프로세스 외부의 불변 의존성이라면 이를 걱정할 필요가 없습니다. 테스트는 내부의 어떤 것도 수정할 수 없기 때문에 서로 실행 컨텍스트에 영향을 줄 수 없습니다. 

 

 

 

 

 

 

 

 

 

예를 들어 외부 API는 변경 기능을 노출하지 않는 한 공유 의존성이 아닙니다. 이는 휘발성이고 애플리케이션의 경계를 벗어나지만 테스트가 반환하는 데이터에 영향을 미칠 수없기 때문에 공유가 아닙니다. 이런의존성은 테스트 범주에 포함하진 않으며, 테스트 대역으로 교체하면 됩니다. **심지어 프로세스 외부 의존성이 충분히 빠르고 연결이 안정적이면 테스트에 그대로 사용해도 됩니다. 

 

 

실제 프로젝트에서 프로세스 외부가 아닌 공유 의존성은 거의 없습니다. 의존성이 프로세스 내부에 있으면 각 테스트에서 별도의 인스턴스를 쉽게 공급할 수 있기 때문에 테스트 간 공유할 필요가 없기 때문입니다. 마찬가지로 공유되지 않는 프로세스 외부 의존성은 일반적으로 접할 일이 없으며, 이런 의존성은 대부분 변경 가능한 테스트로 수정될 수 있습니다. 

 

 

 

 

통합 테스트

두 분파는 통합 테스트에서도 견해의 차이가 있는데 런던 파는 격리된 방식으로 이를 처리하며 고전파는 다른 테스트와 별도로 처리한다. 

단위 테스트는 단일 동작 단위를 검증하고 빠르게 수행되며, 다른 테스트와 별도로 처리된다. 통합 테스트는 이러한 기준 중 하나 이상을 충족하지 않는 테스트다.

 

1. 데이터베이스의 경우 다른 테스트와 분리해 실행할 수 없다. 어떤 데이터 베이스의 상태 변경이 생기면 병렬로 실행할 때 동일 데이터베이스에 의존하는 다른 모든 테스트의 결과가 변경된다. 이 간섭을 피하려면 ㅊ추가 조치를 취애해야 한다. 특히 이런 테스트는 순차적으로 실행해서 각 테스트가 공유 의존성과 함께 작동하려고 기다릴 수 있다. 

 

 

2. 여기서 외부 의존성에 접근하면 테스트가 느려지는데, 데이터베이스에 대한 호출은 실행 시간에 수백 밀리초를 추가한다. 동일한 메모리 공간에 있는 객체 간 통신은 별도 프로세스 간 통신보다 훨씬 저렴하다. 테스트가 메모리 내 객체 수백 개와 함께 동작하더라도 데이터베이스 호출보다 빠르게 실행될 것이다. 

 

 

3. 둘 이상의 동작 단위를 검증할 때의 테스트는 통합 테스트다. 테스트 스위트의 실행 속도. 비슷한 단계를 거치지만 다른 동작 단위를 검증하는 느린 테스트가 두 개 있을 때 하나로 합치면 조금 더 빠르게 검증할 수 있다. 이는 이미 느려서 통합 테스트였기 때문에 결정적인 테스트는 아니다. 또한 다른 팀이 개발한 모듈이 둘 이상 있을 때 통합 테스트로 어떻게 작동하는지 검증할 수 있다. 

 

 

 

통합 테스트는 공유 의존성, 프로세스 외부 의존성 뿐 아니라 조직 내 다른 팀이 개발한 코드 등과 통합해 작동하는지도 검증하는 테스트다. 여기에는 엔드 투 엔드 테스트가 존재하는데, 이는 코드가 프로세스 외부 종속성과 함께 어떻게 작동하는지를 검증한다. 이 둘의 차이점은 엔드 투 엔드 테스트가 일반적으로 의존성을 더 많이 포함한다는 것이지만 둘의 경계는 모호하다.

 

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