TDD-02

🎭 테스트 더블 (Test Double): Mock과 Stub

테스트 더블(Test Double)은 실제 객체(Real Object)를 대신하여 테스트를 위해 사용되는 모든 종류의 대역 객체를 의미합니다. 외부 시스템(DB, API 등)에 대한 의존성을 제거하여 독립적이고, 빠르며, 신뢰성 높은 테스트 환경을 구축하는 데 핵심적인 역할을 합니다.

그중 가장 대표적인 것이 Mock과 Stub입니다.

• Mock (행위 검증)

  특정 함수가 호출되었는지, 정해진 행동을 수행했는지 검증하는 데 사용되며, 객체의 행동(Behavior)에 초점을 맞춥니다.

  예시: verify(mockRepository, times(1)).save(any(User.class)); 와 같이 save 메서드가 1번 호출되었는지 검증합니다.

• Stub (상태 제어)

  미리 준비된 응답을 제공하여 테스트가 원하는 특정 상태를 갖도록 만드는 데 사용되며, 객체의 상태(State)에 초점을 맞춥니다.

  예시: when(stubRepository.findById(1L)).thenReturn(Optional.of(user)); 와 같이 findById(1L)이 호출되면 미리 준비된 user 객체를 반환하도록 설정합니다.

Mock은 Stub의 기능을 포함할 수 있습니다. 둘을 구분하는 핵심 기준은 ‘검증의 목적’입니다.

검증하려는 목적이 ‘특정 메서드의 호출 여부’라면 Mock을, ‘테스트 실행을 위한 특정 상태나 반환 값’이 중요하다면 Stub을 사용하는 것이 좋습니다.

---

🔺 테스트 피라미드 (Test Pyramid) 및 테스트 종류

테스트 피라미드는 효과적인 테스트 전략을 시각적으로 나타내는 모델입니다. 피라미드의 각 층은 테스트의 종류, 범위, 비용, 실행 속도 간의 관계를 보여줍니다.

가장 효율적인 테스트 전략은 피라미드의 아래쪽(단위 테스트)에 집중하고, 상단부(E2E 테스트)는 최소화하는 것입니다.

🧪 Unit Testing (단위 테스트)

• 🎯 대상: 단일 기능, 함수, 클래스와 같은 가장 작은 코드 블록.
• 🔍 목적: 코드 조각이 독립적으로 정확하게 동작하는지 빠르게 검증합니다.
• ✨ 특징: 외부 시스템 의존 없이 메모리 상에서 매우 빠르게 실행됩니다. 코드 변경 시 가장 먼저, 그리고 가장 자주 실행되어 즉각적인 피드백을 제공합니다.
• ✍️ 작성 시점: 모든 개발자가 코드 작성과 동시에 가장 빈번하게 작성하는 기본 테스트입니다.

“강의에서는 다른 객체나 시스템에 의존하지 않고, 온전히 자신의 기능만 테스트하는 독립적인 테스트라고 정의합니다.”

🧩 Integration Testing (통합 테스트)

• 🎯 대상: 서로 다른 모듈, 컴포넌트, 서비스 간의 상호작용.
• 🔍 목적: 여러 모듈이 통합되었을 때 예상대로 협력하고 동작하는지 검증합니다.
• ✨ 특징: 단위 테스트보다 넓은 범위를 다루며, Mock을 사용하거나 실제 시스템(e.g., In-memory DB)을 활용할 수 있습니다.
• ✍️ 작성 시점: 핵심 비즈니스 로직이나 서비스 간의 중요한 상호작용 지점을 검증할 때 작성합니다.

실무에서는 목적에 따라 두 종류로 나눌 수 있습니다.

1. 개발 레벨 통합 테스트: 애플리케이션 내부에서 여러 컴포넌트(Controller-Service-Repository)가 정상적으로 연동되는지 검증합니다. (JUnit + @SpringBootTest, Testcontainers, H2 등을 사용)

   단위 테스트와 달리 “실제 Bean 간 연동, DB 트랜잭션 등 실제 환경에 가까운 상황을 검증”하는 데 목적이 있습니다.

2. QA/배포 단계 통합 테스트 (SIT): 여러 서비스가 통합된 환경(e.g., Staging)에서 전체 시스템의 연동을 확인합니다. 주로 QA팀이 시나리오 기반으로 테스트를 수행합니다.

🖥️ End-to-End Testing (E2E 테스트)

• 🎯 대상: 실제 사용자의 시나리오와 동일한 전체 애플리케이션의 흐름.
• 🔍 목적: 최종 사용자 관점에서 시스템 전체가 처음부터 끝까지 정상 작동하는지 검증합니다.
• ✨ 특징: 실제와 동일한 환경에서 수행되므로 신뢰도가 높지만, 작성 비용이 크고 실행 시간이 매우 깁니다. 따라서 핵심 시나리오에 대해서만 최소한으로 작성해야 합니다.
• ✍️ 작성 시점: 배포 직전, 시스템의 최종적인 안정성을 보장하기 위해 실행합니다. (Cypress, Playwright, Selenium, RestAssured 등의 도구를 사용)

---

📝 Testable Code 작성법과 주의사항

• 모든 프로덕션 코드는 테스트 가능하게(Testable) 구현하는 것을 목표로 삼습니다.
• 테스트 커버리지 100%에 집착하기보다, 의미 있고 신뢰성 높은 테스트를 작성하는 데 집중합니다.
• 테스트 작성을 어렵게 만드는 코드(e.g., private 메서드, 강한 결합)는 리팩토링을 통해 개선합니다.
• 테스트의 성공이 곧 기능 구현의 완료를 의미하도록 개발 프로세스를 정립합니다.

---

🛠️ 실무 테스트 코드 작성 시 고려사항 및 규칙

실무에서는 단위 테스트를 기본으로 삼는 것이 가장 안정적이고 효율적입니다. 단위 테스트는 외부 요인으로부터 개발자를 보호하는 가장 강력한 방어 수단입니다.

✅ 지켜야 할 테스트 코드 규칙

• 한 테스트는 한 가지 책임만 검증: 각 테스트는 명확한 단일 목적을 가져야 합니다.
• 외부 의존성 제어: 실제 DB나 외부 API 대신 Mock 객체를 사용하여 테스트의 독립성과 속도를 확보합니다.
• 테스트 재현성 확보: 실행할 때마다 결과가 달라지는 랜덤 값이나 현재 시간(e.g., LocalDateTime.now())에 의존하는 코드를 제거하여 일관된 결과를 보장합니다.
• 명확한 테스트 이름 (Given-When-Then): 테스트의 조건(Given), 실행(When), 기대 결과(Then)가 드러나도록 이름을 지어, 이름만 봐도 테스트의 의도를 파악할 수 있게 합니다.
• 명확한 Assertion: isTrue(), isNotNull()과 같은 모호한 검증 대신, 기대하는 값이나 상태를 명확히 명시합니다. (e.g., isEqualTo(expectedValue))

❌ 피해야 할 안티패턴

• 테스트 간 상태 공유: 테스트는 서로 독립적이어야 합니다. @BeforeEach 등을 활용하여 매번 깨끗한 상태에서 시작하도록 합니다.
• Thread.sleep() 사용: 테스트를 느리고 불안정하게 만듭니다. 비동기 코드를 테스트할 때는 Awaitility와 같은 전문 라이브러리를 사용합니다.
• 의미 없는 테스트 이름: test1(), doTest()와 같이 목적을 알 수 없는 이름은 지양합니다.
• 과도한 Mock 검증: 내부 구현에 너무 깊이 관여하는 테스트는 리팩토링을 방해합니다.

“이 메서드가 몇 번 호출되었나”와 같은 내부 구현 방식에 집착하기보다, “그래서 최종적으로 외부로 보이는 결과가 무엇인가” 라는 행위(Behavior) 중심의 검증에 집중하는 것이 더 견고한 테스트를 만듭니다.