단위 테스트, 통합 테스트에 대한 방향 잡기

1. 테스트에 대해서 공부하게 된 계기

기존에는 테스트를 API 구현 완료 후 Postman으로 구동 확인 위주로 하였다.
테스트코드를 작성하는 방법도 몰랐고 중요성도 크게 몰랐었다.

 

하지만 이번에는 실제 서비스 해야하는 애플리케이션이고 서비스후에도 계속 수정사항이 발생할 것이기 때문에 테스트코드를 작성해놓지 않는다면 정말 힘들어질 것 같다는 생각이 들었다.

 

하지만 단위 테스트는 어떻게 하는 것인지? 단위 테스트와 통합 테스트의 차이가 무엇인지? 전혀 몰랐다.
따라서 단위 테스트 라는 책을 읽고 예시 상황을 정리해보며 생각을 정리해봤다.

---

2. 단위 테스트란?

정의
모듈이나 애플리케이션 내부에 있는 작은 코드 조각이 예상과 똑같이 동작하는지 검증하는 반복적인 행위

속성

- 프로그램의 작은 코드 조각 단위를 검증
- 빠르고 신속하게 수행
- 격리된 방식으로 처리

사용할 수 있는 도구

Junit5, Mockito( BDDMockito !! )

아직까지는 단위테스트가 뭔지 이해가 잘 안간다.
어떻게 작은 코드 조각으로 나누어야 하고 격리시켜야 하는 것인지..

---

3. 단위 테스트에 대한 해석 차이

역시나 정의만 보면 해석의 차이가 생길 수 밖에 없다.
단위 테스트에 대한 해석의 차이를 두고 런던파와 고전파가 나뉘게 된다.

✏️ 런던파와 고전파 - "작은코드조각"의 기준 차이

단위 테스트는 프로그램의 작은 코드 조각 단위로 검증하는 것이라고 했다. 이에 대한 의견이 나뉜다.

런던파는 작은 코드조각을 테스트 대상 단일 클래스 또는 해당 클래스 내의 메서드 로 본다.
클래스나 메서드라는 단위에 집중한다는 것을 알 수 있다.

고전파는 작은 코드 조각을 테스트 대상의 공유 의존성을 가지지 않은 협력자를 포함한 여러 클래스 로 본다.
동작 단위에 집중한다는 것을 알 수 있다.

공유 의존성은 DB나 File System과 같이 테스트간에 영향을 미칠 수 있는 수단을 제공하는 의존성을 의미한다.

여기까지만 보더라도 런던파가 더 꼼꼼히 테스트하는것 처럼 보이지만 너무 딱딱한 방식이다는것을 알 수 있다.

 

✏️ 런던파와 고전파  요약

1. 런던파
- 테스트 대상 클래스를 협력자로부터 격리
- 불변 의존성 외의 모든 의존성을 대역으로 대체

2. 고전파
- 각각의 테스트 메서드를 서로 간섭없게 격리
- 공유 의존성만 대역으로 대체

---

4. OrderService를 런던파와 고전파가 테스트한다면?

EX) 예시 상황으로 아래와 같이 OrderService에서 OrderRepository를 참조하고 Order에 의존하고 있다고 가정해보자.
Order는 내부적으로 OrderItem를 참조하고, OrderItem은 Item을 참조하고 있다.

 

Case1. 내가 런던파인 경우

공유 의존성인 OrderRepository와 변경 가능 의존성인 Order 클래스를 Mock으로 대체하여 테스트한다.

이렇게 되면 OrderRepository는 물론, Order 클래스 내부를 전혀 테스트할 수 없고 따로 테스트 코드를 작성해야 한다. 

 

Case2. 내가 고전파인 경우

공유 의존성인 OrderRepository를 Mock으로 대체한 것은 런던파와 동일하다.

하지만, 변경 가능 의존성인 Order의 경우에는 대체 하지 않고 그대로 연결하여 테스트한다는 점이 다르다.

---

5. 나는 고전파이다!

런던파 주장 1. 테스트가 매우 작은 단위로 나뉘어 있어 한 클래스에만 집중할 수 있다.
-> 반박:  테스트는 코드의 단위가 아닌 동작의 단위에 Focus 하는게 이상적이라고 생각한다.

런던파 주장 2. 객체 그래프가 복잡해져도 대역으로 대체되기 때문에 상관이 없다.
-> 반박: 고전파를 따른다면 테스트 대상의 협력자인 객체 그래프를 모두 생성해야 하므로 작업이 많다고 생각할 수 있다.
하지만, 이걸 생각하기 전 객체 그래프가 너무 복잡해지는 경우에는 설계 문제를 의심해야 한다고 생각한다.

런던파 주장 3. 테스트 실패시 대상 클래스만 확인하면 되므로 원인 파악이 쉽다.
-> 반박:  고전파를 따른다면 버그가 있는 클래스를 참조하는 모든 테스트가 실패할 수도 있긴 하다.
하지만, 이 경우에는 원래 성공하던 테스트가 있었고 갑자기 실패한다면 방금 내가 고쳤던 코드에 의한 것이므로 원인 파악이 어렵지 않다.

 

위의 이유와 함께 프로그래밍은 효율적인 부분도 챙겨야 한다고 생각하기에 나는 고전파를 따르기로 했다.
물론, 정말 중요한 도메인이고 도메인 로직이 풍부하면 Order를 따로 테스트할 수도 있다고 생각한다. (런던파를 존중)

---

6. 단위 테스트는 알겠고, 통합 테스트는 뭐지?

단위테스트만으로는 애플리케이션이 제대로 동작하는지 알 수 있는 방법이 없다.
왜냐하면 내가 Mock으로 공유 의존성을 끊어냈기 때문이다.

 

단위 테스트를 통해 내 도메인과 서비스를 풍부하게 테스트하였다면 이제는 DB나 파일 시스템과 같은 공유 의존성을 연결하여 통합적인 테스트를 하는것이 중요하다.

 

Presentation 또는 Service Layer를 대상으로 공유 의존성을 연결하여 통합 테스트를 할 수 있다.
일반적으로 가장 긴 주요 흐름과 단위 테스트에서는 검증하지 못한 예외 상황을 모두 다루면 된다.
(물론 Repository만을 따로 테스트할 수도 있다.)

 

통합테스트도 기준이 모호하다고 생각할 수 있다. 하지만 아래와 같이 단위테스트와 비교할 수 있다.

 

단위테스트는 단일 동작을 검증하고, 빠르게 수행하고, 다른 테스트와 격리되어 실행한다는 요구사항이 있었다.
통합테스트는 단위 테스트의 요구사항을 하나라도 만족하지 못하면 통합테스트라고 생각할 수 있다.

 

물론 통합 테스트도 작성해야하지만 외부 프로세스를 모두 연결하고 테스트하는것은 비용이 많이 들고 느리다.
따라서, 통합테스트보다 비용이 저렴한 단위 테스트를 더 많이 작성하려고 해야한다. 

---

7. 통합 테스트 외부 의존성 종류

관리 의존성
- 대표적으로 데이터베이스가 있으며, 관리 의존성은 애플리케이션을 통해서만 접근할 수 있으며, 해당 의존성과의 상호 작용은 외부 환경에서 볼 수 없다.

비관리 의존성
- 대표적으로 SMTP가 있으며, 해당 의존성과의 상호 작용을 외부에서 볼 수 있다. 

관리 의존성은 실제 인스턴스를 사용하면 되고, 비관리 의존성은 Mock으로 대체하여 통합테스트한다.

 

현재 개발하고 있는 플랫폼에도 네이버 SMTP를 이용한 이메일 인증과 같은 기능이 있다. 이러한 부분에 대해서는 어떻게 테스트 해야할지 막막하다.
이 부분에 대해서는 Mock으로 대체하고 End To End 테스트에서 확인 하면 충분하다고 생각한다.

---

✏️ 후기

테스트를 어떻게 해야할지 전혀 감을 못잡고 있었는데 책이나 여러 강의 자료를 보고 방향을 잡게 되었다.

통합 테스트만 하면 되는거지 왜 단위 테스트를 작성하는거지? 라고 생각했지만 오산이었다.

 

실제 프로젝트에서 특정 부분 코드를 고치거나 추가할시에 통합 테스트만 존재한다면 DB와 관련된 부분이 아니더라도 테스트할 때 DB를 연결해야 하며 많은 리소스가 추가로 발생한다.

 

단위 테스트는 속도가 훨씬 빠르고 DB와 관련된 코드를 제외하고 테스트할 수 있어서 내 어플리케이션 코드만 작은 단위로 검증할 수 있기 때문에 꼭 필요한 테스트라는걸 알게 되었다.