테스트를 넘어 제품 개발 관점에서 Mock 바라보기

테스트 목적으로 실제 객체나 시스템을 대신하여 사용하는 모든 종류의 가짜 객체를 ‘테스트 더블(Test Double)’ 이라고 한다.

테스트 더블에는 Stub, Fake, Spy, Mock 등 여러 종류가 있으며, 이 중 Mock은 사전에 정의한 호출이나 상호작용에 대한 명세를 기반으로 동작을 검증하는 데 사용된다. 예를 들어 특정 메서드가 호출되었는지, 어떤 인자가 전달되었는지, 몇 번 호출되었는지 등을 검증할 수 있다.

일반적으로 Mock은 이메일 발송, 결제와 같이 서버에 사이드 이펙트를 발생시키거나 외부 환경에 의존하는 부분을 테스트할 때 자주 사용된다.

이러한 Mock을 테스트를 넘어 제품 개발 관점에서 바라보면 매우 유용하게 활용할 수 있는 지점이 있다.

팀 간 개발 병목을 제거하는 Mock

E-Commerce, Connected Service 등 하나의 제품을 여러 팀들이 협업하여 개발하는 과정을 상상해보자.

하나의 제품을 만들기 위해 여러 팀이 각자의 서버, 애플리케이션, 디바이스 등을 개발하고, 이들은 API와 같은 명확한 계약(Contract)을 통해 서로 통신한다.

예를 들어 A팀이 B팀에서 개발하는 API를 사용해야 한다고 하자. 그런데 B팀의 개발 일정이 늦어지고 있거나, B팀이 담당하는 서버 또는 디바이스의 특성상 API를 추가하거나 변경하는 작업이 쉽지 않을 수 있다. 이 경우 B팀의 개발 일정이 A팀의 개발 일정까지 지연시키는 병목(Bottleneck)이 된다. A팀 입장에서는 실제 B팀의 API가 완성될 때까지 아무것도 할 수 없는 상황이 발생하는 것이다.

이때 Mock Server를 활용할 수 있다.

A팀은 B팀의 API 계약을 기반으로 실제 B팀의 서버가 아직 구현되지 않았더라도 동일한 인터페이스를 제공하는 Mock Server를 먼저 구성할 수 있다. 그리고 A팀에서 개발하는 기능은 실제 B팀의 서버 대신 Mock Server를 바라보도록 구성한다. 이를 통해 A팀은 B팀의 구현이 완료되기를 기다리지 않고 UI/UX, 비즈니스 로직, 예외 상황 등을 먼저 개발하고 테스트할 수 있다.

따라서 Mock은 팀 간의 개발 의존성을 분리하고, 계약을 기준으로 병렬 개발을 가능하게 만드는 도구로 활용될 수 있다.