인프런 커뮤니티 질문&답변

유상원님 안녕하세요. 강의 수강해주시고 좋은 질문 남겨주셔서 고맙습니다. 🙂

질문에 대해서 제 생각을 말씀드리겠습니다.

저는 테스트를 작성할 때 이런 것들을 중요하게 생각합니다.

1. 요구사항을 false negative 없이 충분히 검증하는가?

2. 엔지니어링 비용 지출이 효과에 비해서 큰가?

그리고 제가 설계할 때 많이 떠올리는 원칙 중 하나는 "Consistency is overrated." 입니다.

마지막으로 "현재 우리가 처한 상황에서 가장 실용적인 선택(장기적 관점까지 고려한)은 무엇인가"를 그 어떤 것보다 가장 중요하게 고민합니다.

잠깐 제 개인 사례를 말씀드리면, 제가 최근 맡은 업무 중 하나는 제어할 수 없는 외부 의존성에 너무 강하게 결합되어 국소적인 클래스 수준으로 밖에 테스트를 작성할 수 없는 시스템의 아키텍처를 개선하는 중장기 계획을 수립하는 것입니다. 이런 상황에서 통합 테스트가 좋은지 나쁜지는 고민할 거리가 아닙니다. 제가 익혀온 이론과 마주한 현실 사이의 차이를 점진적으로 줄일 명확하고 단계적인 전략이 필요합니다.

다시 돌아가서 제 동료가 상원님과 같은 의견을 저에게 제시했다면 저는 이런 질문을 드릴 것 같습니다.

1. '많이 좋지 않은 테스트 환경'을 개선할 수는 없을까? 그것이 먼저 고려해야 할 근본적인 원인은 아닐까?

2. 많은 시간이 소비될 가능성이 크다고 했는데 가능성은 어느 정도이며 늘어나는 시간은 어느 정도인가?

3. 많은 시간이 소비되는 것이 모든 곳에서 일관되게(consistently) 발현될 문제인가?

4. 단위 테스트 분류가 반드시 필요하다고 주장하는 사람들 혹은 mockist들은 클래스 범위를 벗어나면 모두 외부라고 지칭한다. 우리가 정의하는 외부는 무엇인가? 그 외부라는 것들은 모두 동일한 특징을 갖는가?(테스트를 동일한 시간으로 느리게 만드는가?)

    

5. 느려서 문제가 되는 테스트가 있다면 그 테스트를 고치는 것과 프로젝트의 모든 영역에 적용되는 단 한가지 일관된(consistent) 규칙을 적용하는 것(최악의 상황을 상정한다면, 그럼으로써 프로젝트 모든 곳에 일관된 false negative 위험성을 퍼뜨리는 것) 중 어떤 것이 더 실용적이고 엔지니어링 정의에 부합하는가?

6. 단위 테스트를 작성하고 false negative 위험성을 보완하기 위해 통합 테스트를 별도로 작성하는 것이 괴롭지는 않은가?(실제로 단위 테스트와 통합 테스트를 구분하던 많은 분들이 저에게 왜 같은 논리에 대한 테스트를 두 번 작성하는지 자괴감이 들지만 또 불안해서 생략하지는 못하겠다며 조언을 물었습니다.)

이런 질문들에 대해 관련된 구성원들의 합의가 도출된다면 그 합의가 무엇이든 신뢰하고 추진할 것 같습니다.

하지만 특정 맥락이 주어지지 않은 상황에서 일반적인 원칙으로 "단위 테스트와 통합 테스트를 잘 분리해야한다."라고 말하는 것은 바람직하지 않습니다. 그렇지 않은 경우가 너무 많기 때문입니다. 대신 "우리 상황은 이러이러하기 때문에 이러이러한 장단점을 고려해서 단위 테스트와 통합 테스트를 잘 분리했다." 라고 말한다면 충분히 존중받을 것입니다.

아주 좋은 질문 남겨주셔서 다시 한 번 감사드리고요, 혹시 답변이 부족했다면 말씀해주세요!

안녕하세요, 인프런 AI 인턴입니다. 유상원님.

질문해 주신 단위 테스트와 통합 테스트의 구분과 활용에 대해 깊이 고민하고 계신 것을 보니, 테스트에 대한 좋은 이해도를 가지고 계신 것 같습니다. 각 테스트 유형의 목적과 특성에 따라 분리해서 사용하는 접근 방식에 대해 설명드리겠습니다.

단위 테스트와 통합 테스트의 구분 및 활용

1. 단위 테스트의 목적과 장점:

   • 외부 의존성 없이 작은 코드 단위(보통 메서드 단위)의 동작을 빠르게 검증할 수 있습니다. 이를 통해 코드 로직에 대한 빠른 피드백이 가능하며, 변경된 코드의 영향을 최소화할 수 있습니다.
     
   • 특히, CI/CD 환경에서 빠른 피드백을 제공하여 개발 생산성을 높이는 데 효과적입니다.
     

2. 통합 테스트의 역할:

   • 시스템의 여러 구성 요소가 서로 잘 동작하는지를 확인합니다. 즉, DB, 외부 API, 스프링 컨텍스트 등 외부 연동이 포함된 시나리오를 테스트합니다.
     
   • 통합 테스트는 상대적으로 실행 시간이 길어질 수 있으며, 복잡한 환경 설정이나 외부 의존성을 처리하는 데 시간이 소요될 수 있습니다.
     

유상원님의 접근 방식

유상원님께서 설명하신 대로, 단위 테스트와 통합 테스트를 명확히 분리하는 전략은 매우 실용적인 접근 방식입니다. 특히, 개발 환경에서는 신속한 피드백을 받기 위한 단위 테스트를 중점적으로 운영하고, CI 환경에서는 포괄적인 테스트를 수행하는 방식이 유리할 수 있습니다.

이러한 접근은 다음과 같은 장점을 제공합니다:
- 빠른 피드백 루프: 테스트 속도가 향상되어 문제를 조기에 발견하고 수정할 수 있습니다.
- 테스트 신뢰성: 각각의 테스트가 고유의 목적과 범위를 가짐으로써, 테스트 실패 시 그 원인을 쉽게 파악할 수 있습니다.
- 효율적인 리소스 사용: 통합 테스트에서는 필요한 경우에만 디테일한 연동 테스트를 수행하여 리소스를 절감할 수 있습니다.

종합적으로, 유상원님의 방식은 각 테스트의 목적을 잘 반영하고 있으며, 많은 실무 개발자들에게 추천할 수 있는 접근법입니다. 큰 틀에서 잘못된 점은 없으며, 다양한 프로젝트 상황에 따라 보완하거나 조정할 수 있는 부분이 있을 뿐입니다.

질문자님의 이해를 돕고자 유사한 고민을 하는 개발자들을 위한 토론 주제를 소개드릴게요:
- 테스트 코드 작성 범위 고민

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.