Mock 객체

Mock 객체를 생성하는 방법은 주로 사용하는 프로그래밍 언어와 테스트 프레임워크에 따라 달라진다. 대부분의 현대적인 단위 테스트 도구는 Mock 객체를 손쉽게 생성할 수 있는 기능을 내장하고 있다. 일반적으로는 Mock 프레임워크가 제공하는 API를 호출하여 원하는 클래스나 인터페이스에 대한 Mock 인스턴스를 만드는 방식이다. 예를 들어, Java의 JUnit과 Mockito를 함께 사용한다면 Mockito.mock() 메서드를, Python의 pytest에서는 unittest.mock 모듈의 Mock() 클래스를 사용하여 생성한다.

Mock 객체 생성의 핵심은 테스트 대상 코드가 의존하는 실제 객체 대신, 제어 가능한 가짜 객체를 주입하는 데 있다. 이를 위해 의존성 주입(Dependency Injection) 패턴이 흔히 활용된다. 테스트 작성자는 생성자를 통하거나 세터(Setter) 메서드를 이용해 Mock 객체를 테스트 대상 객체에 넘겨준다. 이렇게 하면 테스트는 데이터베이스나 외부 API 같은 느리고 불안정한 실제 의존성과 분리되어 실행 속도가 빨라지고, 외부 요인에 영향을 받지 않는 격리된 환경을 구성할 수 있다.

생성된 Mock 객체는 처음에는 아무런 동작도 정의되어 있지 않은 '빈 껍데기' 상태이다. 따라서 테스트 시나리오에 맞게 특정 메서드가 호출될 때 어떤 값을 반환할지(행위 정의, Stubbing) 또는 메서드가 특정 조건으로 호출되었는지(행위 검증, Verification)를 이후 단계에서 설정해야 비로소 유용한 테스트 더블이 된다. 생성 단계는 단지 원본 객체의 형식(Type)을 따르는 가짜 인스턴스를 메모리에 만드는 과정에 불과하다.

행위 정의는 Mock 객체를 사용하는 핵심 단계로, 테스트 더블이 테스트 중에 어떻게 반응해야 하는지를 미리 지정하는 과정이다. 이를 스터빙(Stubbing)이라고도 부른다. 테스트 작성자는 Mock 객체의 특정 메서드가 호출될 때 어떤 값을 반환할지, 또는 어떤 예외를 발생시킬지 등을 사전에 정의한다. 이렇게 함으로써 테스트 대상 객체는 외부 데이터베이스나 네트워크 호출과 같은 실제 의존성과 상호작용하지 않고도, 예측 가능한 환경에서 격리되어 테스트될 수 있다.

스터빙은 일반적으로 "given-when-then" 패턴을 따른다. 즉, "주어진(Mock 객체의 행위가 정의된) 조건에서, 테스트 대상 메서드를 실행하면(when), 기대하는 결과(then)가 나와야 한다"는 논리로 테스트를 구성한다. 예를 들어, 사용자 정보를 조회하는 외부 API를 호출하는 메서드를 테스트할 때, 해당 Mock 객체의 getUserInfo 메서드에 대해 "아이디 'testUser'가 입력되면, 미리 준비된 가짜 사용자 객체를 반환하라"고 행위를 정의할 수 있다. 이를 통해 네트워크 지연이나 서버 장애 없이도 메서드의 논리만을 빠르고 안정적으로 검증할 수 있다.

대부분의 Mock 프레임워크는 풍부한 스터빙 API를 제공하여 다양한 시나리오를 쉽게 정의할 수 있도록 돕는다. 연속적인 호출에 대해 각기 다른 값을 반환하도록 설정하거나, 특정 타입의 인자를 받았을 때만 반응하도록 조건을 걸 수도 있다. 이렇게 사전 정의된 행위는 해당 테스트 케이스의 범위 내에서만 유효하며, 테스트의 독립성을 보장하는 데 기여한다.

검증은 Mock 객체를 사용하는 핵심 목적 중 하나로, 테스트 대상 객체가 의존하는 Mock 객체와의 상호작용이 예상대로 이루어졌는지를 확인하는 과정이다. 단순히 특정 메서드가 호출되었는지 여부뿐만 아니라, 호출 횟수, 전달된 인자 값, 호출 순서 등 세부적인 상호작용을 검증할 수 있다.

대부분의 Mock 프레임워크는 이러한 검증을 위한 전용 API를 제공한다. 예를 들어, 특정 메서드가 정확히 한 번 호출되었는지, 혹은 전혀 호출되지 않았는지를 검증하거나, 메서드가 특정 인자 값과 함께 호출되었는지를 확인할 수 있다. 이는 단위 테스트가 단순히 결과 값의 정합성뿐 아니라, 객체 간의 협력 관계와 프로그램 로직의 흐름이 설계 의도대로 구현되었는지를 검증하는 데 필수적이다.

검증은 주로 테스트 메서드의 실행 단계 이후, 즉 테스트 대상 코드를 실행한 후에 수행된다. 이는 테스트의 '준비-실행-검증' 단계 중 마지막 단계에 해당한다. 검증이 실패하면 테스트는 실패로 처리되며, 이는 Mock 객체와의 예상되지 않은 상호작용이 발생했음을 의미한다.

검증 기능을 통해 개발자는 외부 데이터베이스나 네트워크 서비스와 같은 실제 의존 객체 없이도, 테스트 대상 객체가 올바른 방식으로 다른 객체와 통신하는지를 보장할 수 있다. 이는 테스트 더블을 사용하는 궁극적인 목적인 테스트의 격리성과 신뢰성을 높이는 데 기여한다.

스텁은 단위 테스트에서 테스트 대상이 의존하는 실제 객체를 대신하여 사용되는 가짜 객체이다. 이는 테스트 더블의 한 종류로, 테스트의 안정성과 속도를 높이기 위해 외부 의존성을 격리하는 데 주로 활용된다. 스텁은 실제 객체의 복잡한 내부 로직이나 외부 시스템과의 상호작용을 단순화하여, 테스트가 특정 조건 하에서만 예측 가능한 방식으로 동작하도록 만든다.

주요 용도는 데이터베이스 조회, 네트워크 호출, 외부 API 연동과 같이 실행 속도가 느리거나 상태가 변할 수 있어 테스트 결과를 불안정하게 만드는 의존 객체를 대체하는 것이다. 예를 들어, 사용자 정보를 조회하는 메서드를 테스트할 때 실제 데이터베이스 서버에 연결하는 대신, 미리 정의된 사용자 데이터를 반환하는 스텁 객체를 사용하면 테스트 실행 시간을 크게 단축하고 네트워크 장애 등의 외부 요인으로부터 테스트를 보호할 수 있다.

스텁의 핵심 특징은 사전에 정의된 동작만을 수행한다는 점이다. 개발자는 테스트 시나리오에 필요한 특정 입력값에 대해 어떤 값을 반환할지, 또는 어떤 예외를 발생시킬지를 스텁 객체에 미리 프로그래밍한다. 이렇게 정의된 동작은 테스트 중에 변경되지 않으며, 스텁 객체가 어떻게 호출되었는지에 대한 검증은 일반적으로 수행하지 않는다. 그 목적은 단순히 테스트 대상 객체에 필요한 응답을 제공하여 테스트를 진행할 수 있는 환경을 조성하는 데 있다.

Mock 객체와의 주요 차이점은 여기에 있다. Mock 객체는 테스트 대상 객체와의 상호작용(예: 특정 메서드가 몇 번 호출되었는지, 어떤 매개변수로 호출되었는지)을 검증하는 데 중점을 두는 반면, 스텁은 그러한 검증 없이 미리 정해진 답변만을 제공하는 데 초점을 맞춘다. 따라서 스텁은 상태 검증 위주의 테스트에, Mock 객체는 행위 검증 위주의 테스트에 각각 더 적합하다고 볼 수 있다.

페이크(Fake)는 테스트 더블의 한 종류로, 실제 객체를 단순화하거나 경량화한 버전을 의미한다. 실제 객체와 동일한 기능적 인터페이스를 제공하지만, 내부 구현은 테스트를 위해 단순화되어 있다. 예를 들어, 실제 데이터베이스나 외부 API 호출 대신 메모리 상의 자료 구조를 사용하여 데이터를 저장하고 조회하는 객체가 페이크의 대표적인 예이다. 이는 테스트의 속도를 높이고 외부 시스템의 불안정성으로부터 테스트를 격리시키는 데 주로 사용된다.

페이크는 스텁(Stub)이나 모의 객체(Mock)와는 구분되는 개념이다. 스텁은 미리 정의된 답변만을 반환하는 수동적인 객체인 반면, 페이크는 실제 로직을 단순화하여 가지고 있어 일정 수준의 능동적인 동작을 수행할 수 있다. 또한 모의 객체가 객체의 상호작용을 검증하는 데 중점을 둔다면, 페이크는 실제 객체를 대체하여 기능 자체를 제공하는 데 중점을 둔다. 따라서 페이크는 테스트 중인 시스템(SUT)이 의존하는 복잡한 컴포넌트를 안정적이고 빠르게 대체할 필요가 있을 때 유용하다.

일반적인 사용 예시로는 다음과 같은 것들이 있다.

페이크를 구현할 때는 실제 객체의 핵심 비즈니스 로직을 정확히 반영해야 하며, 너무 단순화하여 테스트의 신뢰성을 떨어뜨리지 않도록 주의해야 한다. 잘 설계된 페이크는 단위 테스트의 효율성을 극대화하는 강력한 도구가 된다.

스파이는 테스트 더블의 한 유형으로, 실제 객체를 감싸거나 부분적으로 대체하면서 해당 객체에 대한 호출 정보를 기록하고 검증할 수 있는 객체이다. 스텁이나 Mock 객체가 가짜 동작을 미리 정의하는 것과 달리, 스파이는 기존의 실제 객체를 그대로 사용하되, 그 객체가 어떻게 사용되었는지(예: 특정 메서드가 몇 번 호출되었는지, 어떤 인자로 호출되었는지)를 모니터링하고 검증하는 데 초점을 둔다.

스파이는 주로 실제 객체의 내부 동작을 변경하지 않으면서도 그 상호작용을 관찰해야 할 때 유용하다. 예를 들어, 복잡한 로직을 가진 서비스 객체의 메서드가 테스트 중에 정상적으로 호출되었는지, 예상한 횟수만큼 실행되었는지를 확인할 때 사용된다. 이는 테스트 대상 코드가 의존하는 객체와 올바르게 협력하는지를 검증하는 행위 주도 개발 시나리오에서 특히 중요하다.

주요 Mock 프레임워크들은 대부분 스파이 기능을 제공한다. 사용법은 일반적으로 실제 객체를 인자로 전달하여 스파이 객체를 생성한 후, 특정 메서드의 호출 여부나 횟수 등을 검증하는 단위 테스트 코드를 작성하는 것이다. 스파이를 사용하면 실제 객체의 대부분의 동작은 그대로 유지한 채, 관심 있는 특정 상호작용만 선택적으로 검증할 수 있다는 장점이 있다.

스파이는 Mock 객체와 유사하게 상호작용 검증에 사용되지만, Mock 객체는 가짜 객체 전체를 정의하는 반면 스파이는 기존 실제 객체를 기반으로 한다는 점에서 차이가 있다. 또한, 단순히 미리 정해진 값을 반환하는 역할만 하는 스텁이나, 실제 동작을 단순화하여 구현한 페이크 객체와도 구분된다.