효과적인 테스트를 위한 모킹 (Mocking) 전략: 언제 모킹하고 언제 하지 말아야 하는가

모킹 (Mocks)은 가장 오용되는 테스트 도구 중 하나입니다. 올바르게 사용하면 테스트를 격리하고 속도를 높여줍니다. 잘못 사용하면 동작 (behavior)이 아닌 구현 세부 사항 (implementation details)을 테스트하는 취약한 테스트를 만듭니다.

내부 세부 사항이 아닌 외부 경계 (external boundaries)를 모킹하세요. 데이터베이스 (database), 외부 API, 파일 시스템 (file system), 그리고 네트워크 호출 (network calls)을 모킹하세요. 이것들은 당신의 코드와 외부 세계 사이의 경계입니다. 이것들을 모킹하면 빠르고 결정론적인 (deterministic) 테스트를 얻을 수 있습니다. 내부 클래스나 함수를 절대 모킹하지 마세요.

페이크 객체 (Fake objects)가 모킹 (mocks)보다 더 나은 경우가 많습니다. 페이크 (fake)는 메모리 내에서 작동하는 외부 인터페이스의 경량 구현체입니다. 인메모리 데이터베이스 (in-memory database), 딕셔너리 (dictionary)로 지원되는 파일 시스템, 또는 메시지를 리스트에 저장하는 페이크 이메일 발신기 등이 그 예입니다. 페이크는 모킹 (mocks)보다 더 견고합니다.

코드 깊숙한 곳이 아닌 API 경계에서 모킹을 설정하세요. 낮은 수준 (low level)에서 모킹을 하면, 내부 구현을 변경하는 리팩토링 (refactoring)이 동작을 바꾸지 않더라도 모킹을 깨뜨리게 됩니다. 가능한 가장 높은 추상화 수준 (abstraction level)에서 모킹하세요.

구현이 아닌 동작 (behavior)을 검증 (Assert)하세요. 특정 메서드가 특정 인자와 함께 호출되었는지 확인하는 대신, 시스템이 예상된 결과를 생성했는지 확인하세요. 이메일 서비스의 send 메서드가 호출되었는지가 아니라, 이메일이 큐 (queue)에 추가되었는지를 검증하세요.

모킹을 가능한 한 최소한으로 하세요. 모든 모킹은 테스트를 덜 현실적으로 만듭니다. 구현체가 빠르고 신뢰할 수 있다면 실제 구현 (real implementations)을 선호하세요. 모킹에 의존하기 전에 인메모리 데이터베이스 (in-memory databases), 테스트 컨테이너 (test containers), 그리고 페이크 서비스 (fake services)를 사용하세요.

모킹 설정은 테스트와 가깝게 유지하세요. 테스트 간에 모킹 설정을 공유하지 마세요. 공유된 모킹의 변경은 관련 없는 테스트를 깨뜨릴 수 있습니다. 각 테스트는 자체적인 기대치 (expectations)를 설정해야 합니다. 이렇게 하면 테스트가 자기 문서화 (self-documenting)됩니다.

Rizwan Saleem | https://rizwansaleem.co