테스트 더블(Test Doubles) 파헤치기: 목(Mock), 스텁(Stub), 스파이(Spy)

테스트 더블 완전 정복: 목, 스텁, 스파이 (Mocks, Stubs, Spies)

전략적인 테스트 더블(Test Doubles)로 유닛 테스트(Unit Tests)의 수준을 높이세요

급변하는 소프트웨어 개발 환경에서 견고하고 유지보수하기 쉬우며 신뢰할 수 있는 코드를 작성하는 것은 가장 중요합니다. 유닛 테스트(Unit Testing)는 이러한 노력의 초석으로서, 버그와 회귀(regression)로부터 시스템을 방어하는 중요한 첫 번째 방어선 역할을 합니다. 하지만 실제 애플리케이션은 거의 독립적으로 존재하지 않습니다. 수많은 외부 서비스, 데이터베이스, 파일 시스템 및 복잡한 내부 구성 요소에 의존합니다. 느리거나, 신뢰할 수 없거나, 비결정적인(non-deterministic) 이러한 의존성(dependencies)으로부터 자유롭게 코드의 단일 유닛(unit)을 독립적으로 테스트하는 것은 상당한 도전 과제입니다. 바로 이 지점에서 테스트 더블(Test Doubles) — 특히 목(Mock), 스텁(Stub), 스파이(Spy) — 의 숙달이 필수불가결한 기술이 됩니다.

Photo by Ferenc Almasi on Unsplash

테스트 더블(Test Doubles)을 마스터하는 것은 단순히 프레임워크를 사용하는 것을 넘어섭니다. 개발자가 유닛 테스트(Unit Test)를 설계하는 방식에 대한 근본적인 패러다임 전환을 이해하는 것입니다. 이는 테스트가 빠르고, 집중적이며, 정확한 피드백을 제공하도록 ‘테스트 대상 유닛’(Unit Under Test, UUT)을 세심하게 격리하는 것을 의미합니다. 현대 개발자에게 이는 단순한 모범 사례(best practice)가 아니라, 코드 품질, 개발 속도(development velocity) 및 궁극적으로 제품 안정성(product stability)에 직접적인 영향을 미치는 핵심 기술입니다. 이 글은 목(Mock), 스텁(Stub), 스파이(Spy)의 개념을 명확히 하고, 실제 적용에 대한 포괄적인 가이드를 제공하여, 보다 효과적이고 통찰력 있는 유닛 테스트를 작성하는 데 필요한 지식을 갖추도록 도울 것입니다.

테스트 더블(Test Doubles) 여정 시작하기

테스트 더블(Test Doubles)을 활용하는 것은 유닛 테스트(Unit Testing) 과정에서 실제 의존성(dependencies)을 제어된 대안으로 대체할 필요성을 인식하는 것에서 시작됩니다. 이제 기본적인 개념과 적용 방법을 살펴보겠습니다.

‘테스트 더블’(Test Double)은 테스트 중에 실제 객체를 대신하는 모든 객체를 지칭하는 일반적인 용어입니다. 사용하는 테스트 더블의 특정 유형은 테스트 목표에 따라 달라집니다.

1. 스텁(Stubs) 이해하기: 제어된 데이터 제공

스텁(Stub)은 테스트 더블 중 가장 간단한 형태입니다. 주된 목적은 테스트 중에 호출되는 메서드에 미리 정의된 답변을 제공하는 것입니다. 스텁 자체는 일반적으로 어떤 것도 검증하지 않으며, 특정 반환 값을 제공하거나 미리 정의된 예외를 발생시켜 테스트를 용이하게 할 뿐입니다.

시나리오:UserRepository에 의존하여 사용자 데이터를 가져오는 UserService를 상상해 보세요. UserService를 테스트할 때, 실제 데이터베이스에 접근하고 싶지 않습니다.

# 원본 UserRepository (의존성)
class UserRepository: def get_user_by_id(self, user_id): # 일반적으로 데이터베이스와 상호작용합니다 raise NotImplementedError("Real database interaction") # 원본 UserService (테스트 대상 유닛)
class UserService: def __init__(self, user_repository): self.user_repository = user_repository def get_user_details(self, user_id): user = self.user_repository.get_user_by_id(user_id) if user: return f"User: {user['name']}, Email: {user['email']}" return "User not found."

스텁(Stub) 사용하기:

import unittest # UserRepository를 위한 간단한 스텁(Stub)
class StubUserRepository: def __init__(self, users_data): self.users_data = users_data def get_user_by_id(self, user_id): return self.users_data.get(user_id) class TestUserServiceWithStub(unittest.TestCase): def test_get_user_details_existing_user(self): # Arrange: 특정 데이터로 스텁(stub)을 설정합니다 stub_data = { 1: {"name": "Alice", "email": "alice@example.com"}, 2: {"name": "Bob", "email": "bob@example.com"} } stub_repo = StubUserRepository(stub_data) user_service = UserService(stub_repo) # Act: 테스트 대상 메서드를 호출합니다 result = user_service.get_user_details(1) # Assert: 스텁된(stubbed) 데이터에 기반하여 결과를 검증합니다 self.assertEqual(result, "User: Alice, Email: alice@example.com") def test_get_user_details_non_existing_user(self): # Arrange: 다른 시나리오를 위해 스텁(stub)을 설정합니다 stub_data = { 1: {"name": "Alice", "email": "alice@example.com"} } stub_repo = StubUserRepository(stub_data) user_service = UserService(stub_repo) # Act result = user_service.get_user_details(99) # Assert self.assertEqual(result, "User not found.") 

이 예시에서 StubUserRepository는 직접 구현한 스텁(hand-rolled stub)입니다. 데이터베이스에 전혀 접근하지 않고 UserService에 예측 가능한 users_data를 제공합니다.

2. 목(Mocks) 이해하기: 상호작용 검증

목(Mock)은 스텁(Stub)보다 더 정교합니다. 스텁이 상태 기반 테스트(state-based testing, 어떤 데이터가 반환되는지)에 중점을 두는 반면, 목은 행동 기반 테스트(behavior-based testing, 객체들이 어떻게 상호작용하는지)에 중점을 둡니다. 목을 사용하면 테스트 대상 객체가 의존성(dependencies)과 어떻게 상호작용할지에 대한 기대를 정의하고, 그 상호작용이 실제로 발생했는지 검증할 수 있습니다.

시나리오: AuditService 의존성(dependency)을 사용하여 사용자가 생성된 후 UserService가 감사 로그(audit log)를 저장하려고 시도하는지 확인하고 싶습니다. AuditService가 로그를 어떻게 저장하는지는 중요하지 않으며, save_log가 올바른 인자(arguments)로 호출되었는지 여부만 중요합니다.

# 원본 AuditService (의존성)
class AuditService: def save_log(self, message): # 파일, 데이터베이스 또는 외부 로그 시스템에 기록합니다 print(f"Saving log: {message}") # 원본 UserManager (테스트 대상 유닛)
class UserManager: def __init__(self, user_repository, audit_service): self.user_repository = user_repository self.audit_service = audit_service def create_user(self, username, email): # user_repository.create_user가 사용자를 저장하고 user_id를 반환한다고 가정합니다 user_id = self.user_repository.create_user(username, email) self.audit_service.save_log(f"User created: {username} (ID: {user_id})") return user_id

목(Mock) 사용하기:현대적인 테스트 프레임워크는 강력한 목킹(mocking) 기능을 제공합니다. 여기서는 특정 도구에 깊이 들어가기 전에 목 사용을 개념화해 보겠습니다.

AuditService에 대한 목(Mock)을 사용하면 다음을 수행할 수 있습니다.

1. 실제 AuditService를 대체합니다.
2. save_log가 특정 메시지와 함께 정확히 한 번 호출될 것이라는 기대를 정의합니다.
3. create_user 메서드가 실행된 후 이 기대를 검증합니다.

이는 목킹(mocking) 라이브러리 사용을 포함하며, 다음 섹션에서 다룰 것입니다. 핵심적인 차이점은 검증 단계에 있습니다.

3. 스파이(Spies) 이해하기: 부분 목킹(Partial Mocking)

스파이(Spy)는 실제 객체를 감싸는 특별한 유형의 테스트 더블입니다. 객체를 완전히 대체하는 목(Mock)과 달리, 스파이는 객체의 실제 메서드를 호출하면서도 해당 객체와의 특정 상호작용을 관찰하고 검증할 수 있게 해줍니다. 이는 클래스의 특정 메서드 하나를 테스트하고 싶지만, 다른 메서드들은 정상적으로 동작하도록 허용하고 싶을 때 유용합니다.

시나리오:이메일을 보내는 NotificationService가 있다고 가정해 봅시다. 이메일 내부에서 일반적인 _send_email 메서드를 호출하는 send_welcome_email 메서드를 테스트하고 싶습니다. _send_email이 올바른 매개변수(parameters)로 호출되는지 확인하고 싶지만, 만약 _send_email이 스파이(spy)에 의해 재정의되지 않았다면 실제 메서드가 여전히 작동하는지도 확인하고 싶습니다.

class NotificationService: def _send_email(self, recipient, subject, body): # 이것은 복잡하거나 외부적인 실제 내부 메서드일 수 있습니다 print(f"Sending email to {recipient}: '{subject}' with body '{body}'") return True def send_welcome_email(self, user_email): subject = "Welcome to our service!" body = "Thank you for joining!" return self._send_email(user_email, subject, body)

스파이(Spy) 사용하기 (개념):NotificationService에 대한 스파이(Spy)는 send_welcome_email이 정상적으로 실행되도록 허용하면서도, _send_email에 대한 모든 호출을 기록하여 다른 호출에 대한 원래 동작을 변경하지 않고도 인자(arguments)를 검증할 수 있게 합니다.

초보자를 위한 단계별 지침은 각 더블의 목적을 먼저 이해한 다음, 구현에 적합한 도구를 선택하는 것입니다. 의존성 주입(Dependency Injection, DI) (클래스의 생성자로 의존성을 전달하는 것)은 테스트 더블 사용을 훨씬 쉽게 만드는 중요한 패턴입니다. 항상 테스트 가능성(testability)을 고려하여 코드를 설계하세요.

테스트 스위트(Test Suite)를 갖추기: 필수 목킹(Mocking) 도구

테스트 더블(Test Doubles)을 효과적으로 구현하려면 올바른 도구가 필요합니다. 최신 프로그래밍 언어는 스텁(Stubs), 목(Mocks), 스파이(Spies)를 생성하고 관리하는 프로세스를 간소화하는 강력한 목킹(mocking) 프레임워크를 제공합니다. 다음은 널리 채택되고 강력히 추천되는 몇 가지 옵션입니다.

1. Python: unittest.mock (표준 라이브러리) 및 pytest-mock (Pytest 플러그인)

파이썬(Python) 개발자를 위해, 파이썬 3.3부터 표준 라이브러리에 포함된 unittest.mock 모듈은 매우 강력합니다. 이 모듈은 목(mock)과 스텁(stub) 역할을 모두 할 수 있는 Mock 및 MagicMock 클래스를 제공합니다.

• 설치:unittest.mock은 설치가 필요 없습니다. pytest-mock (Pytest를 사용하는 경우)의 경우:

  pip install pytest-mock
  

• 사용 예시 (Python unittest.mock):

  from unittest import TestCase, mock class ExternalService: def fetch_data(self, key): raise ConnectionError("Real network call failed") def process_data(self, data): return f"Processed: {data}" class MyApplicationLogic: def __init__(self, external_service): self.external_service = external_service def get_and_process(self, key): try: data = self.external_service.fetch_data(key) return self.external_service.process_data(data) except ConnectionError: return "Failed to fetch data." class TestApplicationLogic(TestCase): def test_get_and_process_success(self): # ExternalService를 위한 Mock 객체 생성 mock_external_service = mock.Mock(spec=ExternalService) # spec은 API 일관성을 보장합니다 # fetch_data에 대한 반환 값 스텁(Stub) 설정 mock_external_service.fetch_data.return_value = "mocked data" # process_data에 대한 반환 값 스텁(Stub) 설정 mock_external_service.process_data.return_value = "fully processed mocked data" app_logic = MyApplicationLogic(mock_external_service) result = app_logic.get_and_process("some_key") self.assertEqual(result, "fully processed mocked data") # fetch_data가 "some_key"로 정확히 한 번 호출되었는지 검증 mock_external_service.fetch_data.assert_called_once_with("some_key") # process_data가 "mocked data"로 정확히 한 번 호출되었는지 검증 mock_external_service.process_data.assert_called_once_with("mocked data") def test_get_and_process_failure(self): mock_external_service = mock.Mock(spec=ExternalService) # fetch_data가 예외를 발생시키도록 스텁(Stub) 설정 mock_external_service.fetch_data.side_effect = ConnectionError app_logic = MyApplicationLogic(mock_external_service) result = app_logic.get_and_process("another_key") self.assertEqual(result, "Failed to fetch data.") mock_external_service.fetch_data.assert_called_once_with("another_key") # process_data가 호출되지 않았는지 확인 mock_external_service.process_data.assert_not_called()
  

• unittest.mock을 사용한 스파이(Spies):mock.patch.object 데코레이터 또는 컨텍스트 관리자를 사용하여 실제 객체의 메서드를 임시로 교체하여 효과적으로 스파이를 생성할 수 있습니다. 그런 다음 패치된 메서드에 대한 호출을 검증할 수 있습니다.

2. Java: Mockito

Mockito는 자바(Java)를 위한 가장 인기 있는 목킹(mocking) 프레임워크라 할 수 있습니다. 목(Mock) 생성, 메서드 스터빙(stubbing), 상호작용 검증을 위한 유연한 API를 제공합니다.

• 설치 (Maven):

  <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.x.x</version> <!-- 최신 버전 사용 --> <scope>test</scope>
  </dependency>
  

• 사용 예시 (Java Mockito):

  // UserRepository와 UserService 클래스가 존재한다고 가정
  import org.junit.jupiter.api.Test;
  import static org.mockito.Mockito.;
  import static org.junit.jupiter.api.Assertions.assertEquals; class User { String name; String email; User(String name, String email) { this.name = name; this.email = email; } public String getName() { return name; } public String getEmail() { return email; }
  } interface UserRepository { User findById(long id); void save(User user);
  } class UserService { private UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public String getUserFullName(long id) { User user = userRepository.findById(id); return user != null ? user.getName() : "Unknown User"; } public void createUser(String name, String email) { User newUser = new User(name, email); userRepository.save(newUser); }
  } public class UserServiceTest { @Test void testGetUserFullName_ExistingUser() { // Arrange: UserRepository의 목(mock) 객체 생성 UserRepository mockRepository = mock(UserRepository.class); // findById 메서드가 특정 사용자를 반환하도록 스텁(Stub) 설정 when(mockRepository.findById(1L)).thenReturn(new User("Jane Doe", "jane@example.com")); UserService userService = new UserService(mockRepository); // Act: 테스트 대상 메서드 호출 String result = userService.getUserFullName(1L); // Assert: 결과와 상호작용 검증 assertEquals("Jane Doe", result); verify(mockRepository, times(1)).findById(1L); // findById가 1L로 한 번 호출되었는지 검증 } @Test void testCreateUser() { UserRepository mockRepository = mock(UserRepository.class); UserService userService = new UserService(mockRepository); userService.createUser("John Smith", "john@example.com"); // save 메서드가 User 타입의 인자(argument)로 정확히 한 번 호출되었는지 검증 // 그리고 인자(argument)를 캡처하여 검사합니다. verify(mockRepository, times(1)).save(any(User.class)); }
  }
  

3. JavaScript/TypeScript: Jest

Jest는 자바스크립트(JavaScript)용, 특히 React 생태계에서 인기 있는 테스트 프레임워크로, 강력한 내장 목킹(mocking) 기능을 포함하고 있습니다.

• 설치:

  npm install --save-dev jest
  

• 사용 예시 (JavaScript Jest):

  // authService.js
  class AuthService { constructor(apiClient) { this.apiClient = apiClient; } async login(username, password) { try { const response = await this.apiClient.post('/login', { username, password }); return response.data.token; } catch (error) { throw new Error('Login failed'); } }
  } // authService.test.js
  import AuthService from './authService'; describe('AuthService', () => { let mockApiClient; let authService; beforeEach(() => { // Jest의 목(mock) 함수를 사용하여 apiClient를 위한 목(mock) 생성 mockApiClient = { post: jest.fn(), // Jest 스파이(spy) 함수 }; authService = new AuthService(mockApiClient); }); test('should return token on successful login', async () => { // post 메서드가 특정 값을 반환하도록 스텁(Stub) 설정 mockApiClient.post.mockResolvedValue({ data: { token: 'mock-token-123' } }); const token = await authService.login('testuser', 'password'); expect(token).toBe('mock-token-123'); // post 메서드가 올바른 URL과 데이터로 호출되었는지 검증 expect(mockApiClient.post).toHaveBeenCalledTimes(1); expect(mockApiClient.post).toHaveBeenCalledWith('/login', { username: 'testuser', password: 'password' }); }); test('should throw error on failed login', async () => { // post 메서드가 에러와 함께 거부되도록 스텁(Stub) 설정 mockApiClient.post.mockRejectedValue(new Error('Network Error')); await expect(authService.login('baduser', 'wrongpass')).rejects.toThrow('Login failed'); expect(mockApiClient.post).toHaveBeenCalledTimes(1); });
  });
  

이러한 도구들은 실제 의존성(dependencies)을 제어된 테스트 더블(Test Doubles)로 대체하는 메커니즘을 제공하여, 정확하고 효율적인 유닛 테스트를 가능하게 합니다. 적절한 도구를 선택하는 것은 주로 사용하는 프로그래밍 언어와 기존 테스트 생태계에 따라 달라집니다.

심층 분석: 실제 테스트 더블 구현 및 패턴

테스트 더블(Test Doubles)의 '무엇’과 '어떻게’를 이해하는 것은 시작에 불과합니다. 이를 숙달하는 것은 실제 시나리오에 효과적으로 적용하고, 모범 사례(best practices)를 준수하며, 일반적인 패턴을 인식하는 것을 포함합니다.

Photo by Logan Voss on Unsplash

코드 예시:

목(Mocks)과 스파이(Spies)를 더욱 명확하게 설명하기 위해 파이썬(Python)의 unittest.mock을 사용하여 UserManager 예시를 확장해 보겠습니다.

import unittest
from unittest import mock # --- 의존성(Dependencies) ---
class AuditService: def log_action(self, action_type, details): # 이 부분이 데이터베이스나 외부 시스템에 로그를 기록한다고 상상해 보세요 print(f"AUDIT LOG: {action_type} - {details}") return True # 성공적인 로깅 시뮬레이션 class EmailService: def send_email(self, recipient, subject, body): # 이 부분이 실제 이메일을 보낸다고 상상해 보세요 print(f"EMAIL SENT to {recipient}: {subject}") return True # --- 테스트 대상 유닛(Unit Under Test) ---
class UserManager: def __init__(self, audit_service: AuditService, email_service: EmailService): self.audit_service = audit_service self.email_service = email_service self.users = {} # 간결함을 위한 인메모리 저장소 def register_user(self, username, email): if username in self.users: return None # 사용자 이미 존재 user_id = len(self.users) + 1 self.users[username] = {"id": user_id, "email": email} # AuditService와의 상호작용 (목(mock)하고 검증하려는 행동) self.audit_service.log_action("USER_REGISTERED", f"New user: {username} (ID: {user_id})") # EmailService와의 상호작용 (스파이(spy)할 수 있는 행동) self.email_service.send_email(email, "Welcome!", f"Hello {username}, welcome!") return user_id def get_user_email(self, username): return self.users.get(username, {}).get("email") 

실용적인 사용 사례 및 모범 사례:

1. 상호작용 검증을 위한 목(Mock) (행동 테스트):

우리는 AuditService에 목(Mock)을 사용합니다. 왜냐하면 UserManager가 AuditService와 상호작용하기 때문입니다. 사용자가 등록될 때 log_action이 특정 인자(arguments)로 정확히 한 번 호출되는지 확인하고자 합니다.

class TestUserManagerWithMock(unittest.TestCase): def test_register_user_audits_action(self): # Arrange mock_audit_service = mock.Mock(spec=AuditService) # AuditService를 목(Mock) 객체로 만듭니다 mock_email_service = mock.Mock(spec=EmailService) # 이메일도 의존성이므로 목(Mock) 객체로 만듭니다 user_manager = UserManager(mock_audit_service, mock_email_service) # Act user_id = user_manager.register_user("testuser", "test@example.com") # Assert (행동 검증) self.assertIsNotNone(user_id) mock_audit_service.log_action.assert_called_once_with( "USER_REGISTERED", f"New user: testuser (ID: {user_id})" ) # 이 테스트에서는 이메일 서비스의 정확한 세부사항에 신경 쓰지 않을 수 있지만, # 정상적인 흐름의 일부로 호출되었는지는 검증합니다. mock_email_service.send_email.assert_called_once()

모범 사례:협업을 검증하고 UUT(테스트 대상 유닛)가 의존성(dependencies)과 올바르게 상호작용하는지 확인하기 위해 목(Mocks)을 사용하세요. 과도한 목킹(over-mocking)은 피하고, 현재 테스트의 단언(assertion)에 필요한 것만 목킹하세요.

2. 실제 객체 관찰을 위한 스파이(Spy) (부분 목킹):

우리는 register_user를 테스트하고 싶지만, EmailService의 send_email 메서드가 호출되는지도 확인하고 싶습니다. 이때 전체 EmailService를 대체하거나 내부 상태에 대해 복잡한 단언(assertion)을 할 필요 없이, 단지 메서드 호출 자체를 확인하고자 합니다. 원한다면 실제 _send_email 메서드가 실행되도록 둘 수도 있습니다.

class TestUserManagerWithSpy(unittest.TestCase): def test_register_user_sends_welcome_email(self): # Arrange mock_audit_service = mock.Mock(spec=AuditService) # 실제 EmailService 인스턴스 생성 real_email_service = EmailService() # real_email_service의 send_email 메서드에 스파이(spy) 생성 # 이 스파이는 메서드를 래핑하여 호출을 단언(assert)할 수 있게 하지만, # 특별히 목(mock)하지 않은 경우 실제 메서드는 여전히 호출됩니다. with mock.patch.object(real_email_service, 'send_email', wraps=real_email_service.send_email) as spy_send_email: user_manager = UserManager(mock_audit_service, real_email_service) # 실제 서비스 주입 # Act user_id = user_manager.register_user("newuser", "new@example.com") # Assert (스파이(spy)에 대한 상호작용 검증) self.assertIsNotNone(user_id) spy_send_email.assert_called_once_with( "new@example.com", "Welcome!", f"Hello newuser, welcome!" ) # 'wraps'가 True이고 side_effect가 제공되지 않았다면 원본 메서드가 호출되었을 것이라는 것을 검증할 수도 있습니다. self.assertTrue(spy_send_email.called) # 메서드가 호출되었습니다 

모범 사례:스파이(Spies)는 실제 객체의 행동을 관찰하고 싶지만, 해당 객체의 다른 메서드들은 정상적으로 작동하게 하고 싶을 때 유용합니다. 완전한 목(Mocks)/스텁(Stubs)보다 덜 일반적이지만 유연성을 제공합니다. 특히 의존성 주입(Dependency Injection)을 위한 완전한 리팩토링(refactoring)이 어려운 레거시 코드베이스(legacy codebases)에 유용합니다.

일반적인 패턴:

• 준비-실행-단언 (Arrange-Act-Assert, AAA):유닛 테스트(Unit Testing)에서 가장 일반적인 패턴입니다.
  • 준비 (Arrange):테스트 더블(Test Doubles)과 테스트 대상 유닛(UUT)을 설정합니다. 목(Mocks)/스텁(Stubs)을 주입합니다.
  • 실행 (Act):UUT(테스트 대상 유닛)에서 테스트하려는 메서드를 실행합니다.
  • 단언 (Assert):UUT의 반환 값/상태 확인(스텁) 또는 목(Mocks)/스파이(Spies)와의 상호작용 검증을 통해 결과를 확인합니다.
• 의존성 주입(Dependency Injection):실제 의존성(dependencies)을 테스트 더블(Test Doubles)로 쉽게 교체할 수 있게 해주는 중요한 아키텍처 패턴입니다. 의존성을 하드코딩(hardcoding)하는 대신, 생성자(constructors)나 세터(setters)를 통해 전달하세요. 이렇게 하면 코드가 더 모듈화되고 테스트하기 쉬워집니다.
• “소유하지 않은 타입을 목킹(Mocking)하지 마세요”:주로 인터페이스(interfaces)나 추상 클래스(abstract classes), 또는 외부 경계(external boundaries)를 나타내는 객체(예: HTTP 클라이언트, 데이터베이스 연결)를 목킹해야 한다는 유용한 지침입니다. 자신이 소유한 구체적인 클래스(concrete classes)를 목킹하면 내부 구현이 자주 변경될 경우 깨지기 쉬운(fragile) 테스트로 이어질 수 있습니다.

이러한 원칙들을 적용하고 올바른 도구를 사용함으로써, 개발자들은 포괄적일 뿐만 아니라 빠르고, 신뢰할 수 있으며, 개발 프로세스에 진정한 자산이 되는 유닛 테스트를 작성할 수 있습니다.

대안 탐색: 테스트 더블(Test Doubles) vs. 통합 테스트(Integrated Tests)

테스트 더블(Test Doubles)을 마스터하는 것이 효과적인 유닛 테스트(Unit Testing)에 중요하지만, 더 넓은 테스트 환경 내에서 그들의 위치를 이해하는 것 또한 중요합니다. 테스트 더블은 격리에는 강력하지만, 만능 해결책은 아닙니다. 개별 구성 요소(components)를 테스트하는 데는 탁월하지만, 해당 구성 요소들이 서로 또는 외부 시스템과 어떻게 통합되는지는 의도적으로 테스트하지 않습니다. 여기서 다른 테스트 접근 방식들이 중요해집니다.

테스트 더블(Mocks, Stubs, Spies) 사용 시기:

• 격리(Isolation):주된 목표는 코드의 단일 유닛(unit)을 그 의존성(dependencies)으로부터 완전히 격리하여 테스트하는 것입니다. 이는 실패한 테스트가 의존성이 아닌, 테스트 대상 유닛(UUT)의 버그를 직접적으로 가리키도록 보장합니다.
• 속도(Speed):테스트 더블(Test Doubles)을 사용하는 유닛 테스트는 I/O, 네트워크 호출, 또는 데이터베이스 트랜잭션(transactions)을 포함하지 않기 때문에 엄청나게 빠릅니다. 이는 개발 중에 빈번한 실행을 가능하게 합니다.
• 비용 효율성(Cost Efficiency):실제 환경(데이터베이스, 외부 서비스)을 설정하고 해체하는 오버헤드를 피할 수 있습니다.
• 엣지 케이스(Edge Cases) 테스트:실제 의존성(dependencies)으로는 재현하기 어려운 오류 조건(예: 네트워크 타임아웃, 데이터베이스 오류)을 쉽게 시뮬레이션(simulate)할 수 있습니다.
• 병렬 개발(Parallel Development):의존성(dependencies)이 완전히 구현되거나 안정화되기 전에도 개발자들이 유닛(unit)을 테스트할 수 있도록 합니다.

예시 통찰: BillingGateway(타사 API)에 의존하는 PaymentProcessor를 테스트하는 경우, 유닛 테스트에서 BillingGateway에 대해 목(Mock)을 반드시 사용해야 합니다. 모든 유닛 테스트에서 실제 결제 게이트웨이에 접근하는 것은 느리고, 비용이 많이 들며, 안전하지 않습니다. BillingGateway를 목(Mock)하여 성공 또는 실패한 결제 응답을 반환하도록 하여 PaymentProcessor의 로직을 철저히 테스트할 수 있습니다.

대안 고려 시기 (또는 보완 시기):

• 통합 테스트(Integration Tests):이 테스트들은 애플리케이션의 다른 유닛(units)이나 구성 요소(components)들이 올바르게 함께 작동하는지 검증합니다. 실제 의존성(dependencies) (또는 인메모리(in-memory) 데이터베이스와 같이 부분적으로 실제인 것)을 포함합니다.
  • 통찰:유닛 테스트(Unit Test)가 UserService가 UserRepository.findById를 올바르게 호출하는지 확인할 수 있지만, 통합 테스트(Integration Test)는 UserRepository.findById가 실제로 데이터베이스를 쿼리하고 올바른 데이터를 반환하는지 확인할 것입니다.
  • 사용 시기:구성 요소 간의 통신 채널, 데이터 매핑(mapping) 및 전체 워크플로우(workflow)가 올바른지 확인하기 위해 사용합니다. 목(Mocks)이 의도적으로 숨기는 문제(예: 잘못된 SQL 쿼리, API 엔드포인트 변경, 직렬화(serialization) 오류)를 찾아냅니다.
• 종단 간(End-to-End, E2E) 테스트:이 테스트들은 UI에서 데이터베이스까지, 그리고 다시 돌아오는 전체 애플리케이션 스택(stack)을 통해 실제 사용자 시나리오를 시뮬레이션(simulate)합니다.
  • 통찰:E2E 테스트는 전체 시스템이 사용자 관점에서 예상대로 작동한다는 가장 높은 신뢰를 제공하지만, 가장 느리고, 비용이 많이 들며, 가장 취약합니다.
  • 사용 시기:핵심 사용자 여정(user journeys), 시스템 수준 검증, 그리고 핵심 기능의 회귀 테스트(regression testing)에 사용합니다.
• 계약 테스트(Contract Tests):이 테스트들은 두 서비스(예: 마이크로서비스(microservice)와 그 클라이언트) 간의 상호작용이 합의된 계약(API 사양)을 준수하는지 검증하며, 두 서비스가 모두 실행될 필요가 없습니다.
  • 통찰:계약 테스트는 서비스 제공자의 API가 여전히 소비자의 기대를 충족하는지 보장함으로써 유닛 테스트(Unit Test)와 통합 테스트(Integration Test) 사이의 간극을 메울 수 있습니다.
  • 사용 시기:분산 시스템, 특히 마이크로서비스 아키텍처(microservices architectures)에서 서비스 간의 파괴적 변경(breaking changes)을 방지하기 위해 사용합니다.

실용적인 통찰: 작업에 적합한 도구 선택하기

결정은 통합 테스트(Integration Tests) 대신 테스트 더블(Test Doubles)을 사용하는 것이 아니라, 균형 잡힌 테스트 전략에서 그것들을 함께 사용하는 것입니다.

• 더블(Doubles)을 사용한 유닛 테스트 우선순위 지정:높은 비율의 유닛 테스트(전체 테스트 스위트의 70-90%)를 목표로 하세요. 이는 즉각적인 피드백을 제공하고 실패 지점을 정확히 찾아냅니다.
• 전략적으로 통합 테스트(Integration Tests) 추가:가장 중요한 구성 요소와 그 직접적인 의존성(예: 서비스 계층이 데이터베이스 계층과 통신하는 방식) 간의 핵심 상호작용을 확인하기 위해 더 작은 통합 테스트 세트(10-25%)를 가지세요. 이는 목(Mocks)이 실제 구성 요소가 어떻게 작동하는지에 대해 잘못된 정보를 주지 않았음을 보장합니다.
• E2E 테스트 최소화:필수 사용자 흐름에 대한 E2E 테스트는 매우 적은 비율(5% 미만)로 유지하세요. 가치 있지만 비용이 많이 듭니다.

다른 테스트 패러다임(testing paradigms)과 비교하여 테스트 더블(Test Doubles)의 강점과 한계를 이해함으로써, 개발자들은 개발 속도를 희생하지 않고도 포괄적인 커버리지(coverage)를 제공하는 견고하고 효율적인 테스트 피라미드(testing pyramid)를 구축할 수 있습니다. 테스트 더블은 빠르고 집중적인 검증을 위한 개발자의 가장 좋은 친구이지만, 더 넓은 시스템 상호작용을 검증하는 테스트로 보완되어야 합니다.

테스트 더블(Test Doubles) 마스터하기: 견고한 소프트웨어로 가는 관문

목(Mocks), 스텁(Stubs), 스파이(Spies)와 같은 테스트 더블(Test Doubles)의 마스터가 되는 여정은 고품질의 유지보수 가능한 소프트웨어를 개발하는 데 있어 중요한 단계입니다. 우리는 이 강력한 도구들이 어떻게 개발자들이 코드를 격리하고, 테스트 주기를 가속화하며, 결함을 정확하게 찾아내어, 종종 부담스러웠던 유닛 테스트(Unit Testing) 작업을 효율적이고 통찰력 있는 실천으로 변화시키는지 살펴보았습니다. 스텁(Stubs)의 기본적인 데이터 제공 역할부터 목(Mocks)의 정교한 상호작용 검증, 스파이(Spies)의 관찰 능력에 이르기까지, 각 테스트 더블은 집중적이고 신뢰할 수 있는 테스트를 작성하는 데 고유한 목적을 수행합니다.

의존성 주입(Dependency Injection)을 수용하고, 파이썬(Python)의 unittest.mock, 자바(Java)의 Mockito, 자바스크립트(JavaScript)의 Jest와 같은 견고한 목킹(mocking) 프레임워크를 활용하며, 준비-실행-단언(Arrange-Act-Assert) 패턴과 같은 모범 사례(best practices)를 적용함으로써 개발자들은 테스트 효율성을 크게 높일 수 있습니다. 핵심적인 시사점은 테스트 더블(Test Doubles)이 포괄적인 테스트를 대체하는 것이 아니라, 통합 테스트(Integration Tests) 및 종단 간 테스트(End-to-End Tests)를 보완하여 견고한 테스트 피라미드(testing pyramid)를 형성하는 잘 갖춰진 전략의 필수 구성 요소라는 점입니다. 견고하고 확장 가능한 애플리케이션 구축에 전념하는 모든 개발자에게 테스트 더블의 전략적 적용은 단순한 기술이 아닙니다. 이는 배포되는 모든 코드 라인에 대한 확신을 뒷받침하는 근본적인 기술입니다.

테스트 더블(Test Double) FAQ 및 핵심 개념 분석

자주 묻는 질문 (FAQs)

1. 목(Mock)과 스텁(Stub)의 주요 차이점은 무엇인가요? 스텁(Stub)은 주로 상태 기반 테스트(state-based testing)에 사용됩니다. 메서드 호출에 미리 준비된 답변을 제공하여, 본질적으로 테스트 대상 유닛(UUT)의 제어된 데이터 소스 역할을 합니다. 목(Mock)은 행동 기반 테스트(behavior-based testing)에 사용됩니다. 메서드 호출에 대한 기대를 설정하고, 해당 기대가 충족되었는지(예: 특정 인자(arguments)로 메서드가 특정 횟수만큼 호출되었는지) 검증할 수 있게 합니다.

2. 목(Mock)이나 스텁(Stub) 대신 스파이(Spy)는 언제 사용해야 하나요? 스파이(Spy)는 실제 객체와의 상호작용을 관찰하고 검증해야 하지만, 동시에 해당 객체의 실제 메서드가 다른 작업에 대해서도 호출되도록 허용하고 싶을 때 사용합니다. 목(Mock)은 실제 객체를 완전히 대체하는 반면, 스파이(Spy)는 객체를 감싸는 형태로 부분 목킹(partial mocking) 기능을 제공합니다. 이는 정상적으로 작동하는 클래스의 특정 메서드만 가로채거나 검증해야 할 때 유용합니다.

3. 목(Mocks), 스텁(Stubs), 스파이(Spies)에 동일한 프레임워크를 사용할 수 있나요? 네, 대부분의 현대 목킹(mocking) 프레임워크(unittest.mock, Mockito, Jest 등)는 스텁(Stubs), 목(Mocks) 역할, 또는 메서드 래핑(wrapping)이나 부분 목킹(partial mocking) 기능을 통해 스파이(Spy)와 유사한 기능을 제공하는 객체를 생성할 수 있을 만큼 다재다능합니다. 이러한 구분은 종종 더블의 초기 생성 방식이 아니라 더블을 어떻게 구성하고 사용하는지에 있습니다.

4. "과도한 목킹(over-mocking)"이란 무엇이며 왜 좋지 않나요? 과도한 목킹(over-mocking)은 너무 많은 목(Mocks)을 생성하거나, 객체의 너무 많은 행동, 특히 내부 구현 세부사항까지 목킹하는 것을 말합니다. 이는 테스트 대상 유닛(UUT)의 외부 동작은 동일하게 유지되더라도 내부 구현이 변경될 때 쉽게 깨지는(fragile) 테스트로 이어집니다. 또한, 관찰 가능한 행동에 초점을 맞추기보다 특정 구현 세부사항에 강하게 결합되어 테스트를 읽고 이해하기 어렵게 만들 수 있습니다.

5. 의존성 주입(Dependency Injection)은 테스트 더블(Test Doubles)과 어떻게 관련되나요? 의존성 주입(Dependency Injection, DI)은 클래스가 스스로 의존성(dependencies)을 생성하는 대신 외부 소스(예: 생성자, 메서드 또는 속성)로부터 의존성을 받는 디자인 패턴입니다. 이는 테스트 중에 실제 의존성 대신 테스트 더블(목, 스텁, 스파이)을 "주입"하는 것을 매우 쉽게 만들어주며, 테스트 대상 클래스를 수정하지 않고도 테스트 더블 사용을 직접적으로 가능하게 합니다.

필수 기술 용어

1. 테스트 대상 유닛 (Unit Under Test, UUT):격리되어 테스트되는 특정하고 가장 작은 코드 조각(예: 메서드, 클래스 또는 함수).

2. 의존성 주입 (Dependency Injection, DI):구성 요소(components)가 내부적으로 의존성(dependencies)을 생성하는 대신 외부로부터 의존성을 받는 아키텍처 패턴으로, 이를 통해 더 모듈화되고 테스트하기 쉬워집니다.

3. 테스트 하네스 (Test Harness):테스트 실행을 조직하고, 테스트 컨텍스트(context)를 설정하며, 테스트를 실행하고, 결과를 보고하는 프레임워크 또는 환경.

4. 행동 주도 개발 (Behavior-Driven Development, BDD):소프트웨어 사용자 요구사항에 대한 사람이 읽을 수 있는 설명을 소프트웨어 테스트의 기반으로 사용하는 소프트웨어 개발 방법론입니다. 목(Mocks)은 예상되는 행동을 정의하고 검증하는 데 도움이 되므로 BDD에서 특히 유용합니다.

5. 테스트 피라미드 (Test Pyramid):빠르고 격리된 유닛 테스트(Unit Tests)의 큰 기반, 더 작은 통합 테스트(Integration Tests)의 중간 계층, 그리고 느리고 광범위한 종단 간 테스트(End-to-End Tests)의 작은 최상위 계층으로 구성된 균형 잡힌 테스트 전략을 제안하는 휴리스틱(heuristic)입니다.

Published on November 14, 2025