스텁 (r1)

스텁은 소프트웨어 개발 과정에서, 특히 단위 테스트를 수행할 때 아직 개발되지 않았거나 테스트 환경에서 직접 사용하기 어려운 컴포넌트를 임시로 대체하기 위해 사용하는 간단한 코드 조각이다. 이는 테스트 더블이라는 더 넓은 범주의 테스트 대체 기술 중 하나에 속한다. 스텁의 핵심은 실제 로직이나 복잡한 동작을 수행하지 않고, 호출에 대해 미리 정해진 고정된 값을 반환하거나 아무런 동작도 하지 않는 것이다.

주요 목적은 테스트 대상 모듈을 고립시켜 검증하는 것이다. 예를 들어, 특정 모듈이 데이터베이스나 외부 API에 의존할 경우, 해당 의존 요소가 준비되지 않았거나 테스트 시 불필요한 부작용을 일으킬 수 있다. 이때 데이터베이스 조회를 대신해 하드코딩된 데이터를 반환하는 스텁을 사용하면, 네트워크 지연이나 데이터 상태 변동 없이 모듈 자체의 로직만을 안정적으로 테스트할 수 있다. 이는 테스트 주도 개발이나 프로토타입 단계에서 인터페이스 설계를 검증할 때도 유용하게 활용된다.

스텁은 일반적으로 실제 객체의 인터페이스나 계약을 그대로 따르지만, 내부 구현은 최소한으로 단순화된다. 가장 기본적인 형태인 더미 스텁은 null이나 0, 빈 문자열 같은 의미 없는 값을 반환하기도 한다. 반면, 호출된 메서드의 인자를 기록하거나 특정 조건에 따라 다른 값을 반환하는 등 약간의 지능을 갖춘 스마트 스텁으로 발전할 수도 있다. 이러한 스텁의 사용은 모의 객체나 페이크 객체와 같은 다른 테스트 더블과 개념적으로 연관되어 있으며, 각각의 정확한 역할과 차이점을 이해하는 것이 중요하다.

스텁의 주요 목적은 테스트 과정에서 아직 구현되지 않았거나 테스트 환경에서 사용하기 어려운 실제 컴포넌트를 대체하여 테스트를 가능하게 하는 것이다. 이를 통해 개발자는 특정 모듈의 구현이 완료되기 전에도 다른 부분의 테스트를 진행할 수 있으며, 외부 시스템에 대한 의존성을 제거하여 테스트의 속도와 안정성을 높일 수 있다.

주요 용도는 크게 네 가지로 구분된다. 첫째는 테스트 지원이다. 단위 테스트나 통합 테스트를 작성할 때, 테스트 대상 코드가 의존하는 외부 모듈이나 서비스가 준비되지 않았거나 테스트 실행을 방해할 경우, 스텁으로 대체하여 테스트를 수행한다. 둘째는 개발 중 의존성 분리이다. 하위 모듈의 개발이 지연되더라도 상위 모듈을 독립적으로 개발하고 검증할 수 있도록 한다. 셋째는 프로토타이핑이다. 시스템의 전체 구조나 인터페이스 설계를 검증하기 위해 실제 기능은 생략한 채 골격만을 빠르게 구현할 때 사용한다. 넷째는 인터페이스 설계 검증으로, 컴포넌트 간의 상호작용 방식을 미리 정의하고 확인하는 데 활용된다.

구체적인 사용 예시로는, 데이터베이스 연결 코드가 준비되기 전에 데이터베이스 호출을 대체하거나, 외부 네트워크 API가 개발 중일 때 해당 API 호출을 임시로 처리하는 경우가 있다. 또한 복잡한 알고리즘의 자리 표시자로 사용되어, 알고리즘의 정교한 구현에 집중하기 전에 주변 로직의 흐름을 먼저 점검하는 데 도움을 준다. 이처럼 스텁은 소프트웨어 개발의 병렬성과 효율성을 크게 향상시키는 도구이다.

스텁은 주로 소프트웨어 개발의 초기 단계나 테스트 과정에서 사용된다. 개발자는 특정 모듈이나 외부 시스템이 아직 준비되지 않았을 때, 해당 부분을 스텁으로 대체하여 나머지 코드의 개발과 테스트를 계속 진행할 수 있다. 예를 들어, 백엔드 API가 개발 중이어서 호출할 수 없는 상황에서, 프론트엔드 개발자는 API를 호출하는 코드 자리에 미리 정해진 더미 데이터를 반환하는 스텁을 만들어 두고 통합 테스트를 수행할 수 있다.

또한, 스텁은 단위 테스트를 작성할 때 복잡한 의존성을 격리시키는 데 유용하게 쓰인다. 테스트 대상 코드가 데이터베이스나 외부 서비스에 의존하는 경우, 이러한 실제 의존성을 실행하는 것은 느리고 환경 구성이 복잡할 수 있다. 이때 데이터베이스 조회 함수나 외부 서비스 호출 함수를 항상 동일한 값을 반환하는 스텁으로 교체하면, 테스트는 실제 환경에 구애받지 않고 빠르게 실행될 수 있으며, 테스트 대상 코드의 로직만을 집중적으로 검증할 수 있다.

스텁은 프로토타이핑이나 인터페이스 설계 검증 단계에서도 활용된다. 시스템의 전체 구조를 설계할 때, 각 컴포넌트 간의 상호작용 방식을 정의한 후 구체적인 구현을 시작하기 전에, 스텁을 사용해 인터페이스 호출 흐름이 정상적으로 동작하는지를 먼저 확인할 수 있다. 이는 설계상의 결함을 조기에 발견하고, 여러 개발자가 병렬적으로 작업을 진행하는 데 도움을 준다.

사용 시기를 정리하면, 스텁은 의존성이 불완전할 때(개발 중), 테스트를 단순화하고 가속화해야 할 때(테스트 중), 그리고 시스템 구조를 검증해야 할 때(설계/프로토타이핑 단계)에 주로 도입된다. 이는 테스트 주도 개발 방법론에서도 빈번히 등장하는 기법으로, 실제 구현을 기다리지 않고도 기능 명세에 따른 테스트 케이스를 먼저 작성하고 실행하는 데 필수적이다.

더미 스텁은 소프트웨어 개발 과정에서 아직 완전히 구현되지 않은 코드나 함수를 임시로 대체하는 가장 단순한 형태의 테스트 더블이다. 이는 실제 로직이나 복잡한 동작을 포함하지 않으며, 단순히 미리 정의된 고정된 값을 반환하거나 아무런 동작도 하지 않는 빈 함수로 구현된다. 주로 단위 테스트나 통합 테스트에서 외부 의존성을 분리하거나, 특정 인터페이스의 설계를 검증하는 목적으로 사용된다.

더미 스텁의 주요 용도는 테스트 중인 코드가 다른 모듈이나 시스템에 의존할 때, 그 의존성을 가짜로 대체하여 테스트를 가능하게 하는 것이다. 예를 들어, 데이터베이스 연결이 준비되지 않았거나, 외부 네트워크 API가 개발 중일 때, 해당 호출을 더미 스텁으로 대체하면 실제 환경 없이도 핵심 로직의 테스트를 진행할 수 있다. 또한 복잡한 알고리즘의 자리 표시자 역할로 프로토타입을 빠르게 구성하는 데에도 활용된다.

더미 스텁은 모의 객체나 페이크 객체와 같은 다른 테스트 더블과 구분된다. 모의 객체는 호출 여부나 호출 횟수와 같은 상호작용을 검증하는 데 중점을 두는 반면, 더미 스텁은 단순히 호출을 받아들이고 미리 정해진 응답만을 제공한다. 이는 테스트의 목적이 특정 객체의 행동을 검증하는 것이 아니라, 단순히 의존성을 채워 테스트 흐름을 완성시키는 데 있다는 점에서 차이가 있다.

더미 스텁은 수동으로 간단한 클래스나 함수를 만들어 구현할 수 있으며, JUnit, Mockito, Jest와 같은 다양한 테스트 프레임워크에서도 지원하는 기능을 통해 손쉽게 생성할 수 있다. 이는 개발 초기 단계나 특정 조건 하에서의 테스트를 간소화하여 개발 생산성을 높이는 데 기여한다.

스마트 스텁은 테스트 더블의 한 형태로, 더미 스텁보다 더 복잡한 동작을 수행할 수 있는 구현체이다. 더미 스텁이 단순히 미리 정의된 고정값을 반환하거나 아무 동작도 하지 않는 것과 달리, 스마트 스텁은 특정 조건에 따라 다른 값을 반환하거나 간단한 로직을 포함할 수 있다. 이는 테스트 중인 시스템이 외부 의존성과 상호작용할 때 보다 현실적이고 다양한 시나리오를 검증하는 데 도움을 준다.

주요 사용 목적은 단위 테스트나 통합 테스트에서 실제 구현이 완료되지 않은 모듈, 느리거나 불안정한 외부 서비스(예: 데이터베이스, 네트워크 API)를 대체하는 것이다. 예를 들어, 사용자 인증 API가 아직 개발 중일 때, 스마트 스텁은 입력된 아이디가 "admin"인 경우에만 성공 응답을 반환하고, 그 외에는 실패 응답을 반환하도록 구현될 수 있다. 이를 통해 호출 측의 로직을 더 풍부하게 테스트할 수 있다.

스마트 스텁은 모의 객체와 유사해 보일 수 있지만, 핵심 차이점이 있다. 모의 객체는 테스트 중에 자신이 어떻게 호출되었는지(호출 횟수, 전달된 인자 등)에 대한 기대사항을 설정하고 이를 검증하는 데 중점을 둔다. 반면 스마트 스텁의 주된 역할은 호출에 대한 미리 정의된 응답을 제공하여 테스트를 진행할 수 있게 하는 것이며, 호출 자체에 대한 검증은 일반적으로 수행하지 않는다.

구현은 수동으로 클래스나 함수를 작성하거나, JUnit, Mockito, Jest와 같은 테스트 프레임워크의 기능을 활용하여 생성할 수 있다. 이러한 도구들은 특정 인터페이스나 클래스를 기반으로 미리 정해진 값을 반환하는 스텁을 쉽게 만들 수 있는 방법을 제공한다.

모의 객체는 테스트 더블의 한 종류로, 소프트웨어 테스트 중에 실제 객체를 대신하여 사용되는 객체이다. 모의 객체는 테스트 대상 코드가 의존하는 외부 컴포넌트나 서비스의 행동을 시뮬레이션하고, 그와의 상호작용(예: 메서드 호출, 인자 전달)을 검증하는 데 중점을 둔다. 이는 단순히 미리 정해진 값을 반환하는 스텁과 구별되는 핵심 특징이다. 즉, 모의 객체는 "어떤 메서드가 특정 인자와 함께 호출되었는가?"와 같은 상호작용의 정확성을 검증하는 감시자 역할을 수행한다.

단위 테스트에서 테스트 대상 모듈은 종종 데이터베이스, 네트워크 API, 파일 시스템 등 다른 모듈에 의존한다. 이러한 의존 객체들을 실제로 사용하면 테스트 실행이 느려지고, 외부 환경에 의존하게 되어 테스트 결과가 불안정해질 수 있다. 모의 객체는 이러한 실제 의존 객체를 대체하여 테스트를 격리시키고, 외부 시스템의 상태나 가용성에 영향을 받지 않도록 한다. 예를 들어, 사용자 정보를 저장하는 데이터베이스 리포지토리 인터페이스에 대한 모의 객체를 생성하여, findUserById 메서드가 호출될 때 미리 준비한 가짜 사용자 객체를 반환하도록 설정할 수 있다.

모의 객체는 일반적으로 Jest, Mockito, Sinon.js, unittest.mock과 같은 테스트 프레임워크나 라이브러리를 통해 생성된다. 이러한 도구들은 객체의 메서드가 호출된 횟수, 전달된 인자, 호출 순서 등을 기록하고, 테스트 어설션(assertion)을 통해 기대한 대로 상호작용이 발생했는지 쉽게 확인할 수 있는 기능을 제공한다. 이는 테스트 대상 코드의 로직 흐름과 외부 모듈과의 통신 프로토콜이 설계대로 구현되었는지를 검증하는 데 매우 유용하다.

모의 객체는 스텁, 페이크, 스파이와 함께 테스트 더블 패밀리를 구성한다. 이들 개념은 종종 혼용되지만, 미묘한 차이가 있다. 스텁은 호출에 대한 미리 정의된 응답을 제공하는 데 주 목적이 있는 반면, 모의 객체는 호출 자체에 대한 기대사항을 설정하고 검증하는 데 중점을 둔다. 페이크는 실제로 동작하는 간소화된 구현체이며, 스파이는 실제 객체의 호출을 가로채 정보를 기록하는 점에서 모의 객체와 유사하지만, 검증보다는 정보 수집에 더 초점을 맞춘다.

수동 구현은 스텁을 생성하는 가장 기본적인 방법으로, 개발자가 직접 간단한 코드를 작성하여 필요한 인터페이스나 클래스를 구현한다. 이는 특별한 라이브러리나 프레임워크에 의존하지 않으며, 테스트나 프로토타입 개발의 초기 단계에서 빠르게 적용할 수 있다. 예를 들어, 아직 개발되지 않은 데이터베이스 조회 함수의 자리에, 하드코딩된 테스트 데이터 목록을 반환하는 함수를 직접 작성하여 배치하는 방식이다.

구현 방식은 매우 직관적이다. 일반적으로 실제 구현체와 동일한 메서드 시그니처를 가지는 클래스나 함수를 만들고, 그 내부에는 미리 정해진 고정값을 반환하거나 아무런 동작도 하지 않는 빈 코드를 작성한다. 단위 테스트에서 외부 API 호출을 대체할 때는, 네트워크 지연이나 오류 없이 즉시 예상된 응답 값을 돌려주는 스텁 함수를 수동으로 만들어 연결한다.

이 방법의 주요 장점은 구현이 간단하고 추가 도구가 필요 없다는 점이다. 특히 작은 규모의 프로젝트나 복잡한 의존성 주입 설정이 필요 없는 경우에 유용하다. 또한, 스텁의 동작을 개발자가 완전히 제어할 수 있어 매우 예측 가능한 테스트 환경을 구성할 수 있다.

그러나 수동 구현은 스텁의 로직이 변경될 때마다 직접 코드를 수정해야 하는 관리 부담이 있다. 다양한 시나리오(예: 정상 반환, 예외 발생, 지연 응답)를 테스트하려면 각 경우에 대한 여러 스텁을 별도로 만들어야 할 수 있다. 따라서 테스트 케이스가 많아지고 스텁의 복잡성이 증가하면, Mockito, Jest, unittest.mock 같은 테스트 프레임워크를 활용한 자동화된 생성 방식이 더 효율적일 수 있다.

스텁을 구현하는 방법 중 하나는 테스트 프레임워크나 모의 객체 생성 라이브러리를 활용하는 것이다. JUnit이나 pytest와 같은 테스트 프레임워크와 함께 제공되거나 통합되는 모킹 라이브러리를 사용하면, 스텁을 수동으로 코딩하는 것보다 훨씬 효율적이고 강력하게 생성하고 관리할 수 있다. 대표적인 라이브러리로는 Java의 Mockito, Python의 unittest.mock, JavaScript의 Jest나 Sinon.JS 등이 있다.

이러한 프레임워크를 활용하면, 개발자는 인터페이스나 클래스를 기반으로 스텁 객체를 동적으로 생성할 수 있다. 특정 메서드가 호출될 때 반환할 값을 미리 정의하거나, 예외를 발생시키도록 설정하는 것이 일반적이다. 예를 들어, 데이터베이스 조회 메서드를 호출하면 하드코딩된 테스트 데이터 목록을 반환하는 스텁을 쉽게 만들 수 있다. 이는 실제 데이터베이스 서버가 없거나, 네트워크 API가 불안정한 개발 초기 단계에서 단위 테스트를 수행하는 데 매우 유용하다.

프레임워크를 통한 스텁 생성의 주요 장점은 생산성과 유지보수성에 있다. 수동 구현에 비해 코드 양이 크게 줄어들고, 테스트의 의도를 더 명확하게 표현할 수 있다. 또한, 의존성 주입과 결합하여 테스트 대상 코드를 외부 의존성으로부터 완전히 격리시킬 수 있다. 하지만, 프레임워크의 학습 곡선이 존재하며, 지나치게 복잡한 스텁 설정은 오히려 테스트 코드를 이해하기 어렵게 만들 수 있다는 점은 주의해야 한다.

스텁을 사용하는 주요 장점은 테스트의 효율성과 개발의 유연성을 크게 향상시킨다는 점이다. 첫째, 스텁은 개발 중인 모듈이 의존하는 외부 시스템이나 다른 모듈이 아직 준비되지 않았을 때도 독립적인 단위 테스트를 가능하게 한다. 예를 들어 데이터베이스 서버가 구축되기 전이나 API가 완성되지 않은 상태에서도, 해당 기능을 호출하는 코드의 로직을 검증할 수 있다. 이는 개발 병목 현상을 해소하고 개발 생산성을 높이는 데 기여한다.

둘째, 스텁은 테스트 환경을 단순화하고 통제 가능하게 만든다. 실제 외부 의존성은 네트워크 상태나 데이터 변경에 따라 테스트 결과가 달라질 수 있지만, 스텁은 항상 정해진 값을 반환하도록 구현된다. 이로 인해 테스트의 결정론이 보장되어 동일한 입력에 대해 항상 동일한 결과를 예측할 수 있다. 따라서 테스트의 신뢰도가 높아지고, 버그를 재현하고 추적하는 데 유리한 환경을 제공한다.

또한, 스텁은 인터페이스 설계를 조기에 검증하는 도구로 활용될 수 있다. 실제 구현에 앞서 함수나 메서드의 시그니처와 예상 동작을 정의한 스텁을 먼저 만들고 사용해 보면, 설계상의 문제점을 초기 단계에서 발견할 수 있다. 이는 프로토타입 개발과 협업 과정에서 특히 유용하며, 전체적인 소프트웨어 아키텍처의 견고함을 높이는 데 도움을 준다.

스텁은 여러 장점에도 불구하고 몇 가지 명확한 단점을 지닌다. 가장 큰 문제는 실제 동작을 대체하지 않는다는 점이다. 스텁은 미리 정의된 고정된 값만 반환하거나 아무 동작도 하지 않기 때문에, 실제 구현체의 복잡한 로직이나 상태 변화, 예외 처리를 검증하는 데는 전혀 도움이 되지 않는다. 이는 테스트의 충분성과 신뢰도를 떨어뜨릴 수 있다.

또한, 스텁을 과도하게 사용하거나 부적절하게 적용할 경우 테스트와 실제 코드 사이의 괴리를 발생시킨다. 즉, 스텁을 사용한 단위 테스트는 모두 통과하더라도, 실제 환경에서 통합되었을 때는 전혀 다른 결과가 나올 수 있다. 특히 데이터베이스나 외부 API와의 상호작용을 대체하는 스텁은 실제 연결 상태, 네트워크 지연, 데이터 무결성 등을 테스트할 수 없어 중요한 통합 오류를 놓칠 위험이 있다.

스텁의 관리 부담도 단점으로 꼽힌다. 프로젝트가 진행되면서 실제 구현체의 인터페이스나 반환 값이 변경되면, 이에 의존하는 모든 스텁도 함께 수정해야 한다. 이는 수동으로 구현된 스텁이 많을수록 유지보수 비용을 증가시키며, 변경 사항을 스텁에 반영하지 못하면 오히려 잘못된 테스트 결과를 초래할 수 있다. 따라서 스텁은 그 목적과 한계를 정확히 이해하고 필요한 상황에만 제한적으로 사용하는 것이 바람직하다.

모의 객체는 테스트 더블의 한 종류로, 단위 테스트에서 실제 객체를 대신하여 사용되는 객체이다. 스텁이 단순히 미리 정해진 값을 반환하는 수동적인 역할을 하는 반면, 모의 객체는 테스트 중에 자신이 어떻게 호출되었는지(예: 어떤 메서드가 몇 번 호출되었는지, 어떤 매개변수가 전달되었는지)를 기억하고 검증하는 능동적인 역할을 한다. 이는 테스트 대상 코드와 협력 객체 간의 상호작용을 검증하는 데 중점을 둔다.

주요 목적은 테스트 자동화 과정에서 외부 의존성(예: 데이터베이스, 네트워크 서비스, 복잡한 라이브러리)을 격리시키는 것이다. 예를 들어, 사용자 인증 서버에 실제로 접속하지 않고도, 모의 객체를 사용해 특정 아이디와 비밀번호가 주어졌을 때 '로그인 성공'이라는 응답을 반환하도록 설정하고, 테스트 코드가 그 응답을 올바르게 처리하는지 확인할 수 있다. 이를 통해 테스트의 실행 속도를 높이고, 외부 시스템의 상태나 네트워크 연결에 영향을 받지 않는 안정적인 테스트 환경을 구성할 수 있다.

모의 객체는 일반적으로 JUnit, TestNG 등의 테스트 프레임워크와 함께 Mockito, JMockit, EasyMock 같은 전용 모의 객체 프레임워크를 활용해 생성한다. 이러한 도구들은 모의 객체의 행동(메서드 호출 시 반환값)을 설정하고, 호출 내역을 검증하는 편리한 API를 제공한다. 모의 객체의 사용은 행위 주도 개발이나 테스트 주도 개발 방법론에서 특히 중요하게 다뤄진다.

모의 객체와 스텁, 페이크 객체, 스파이는 모두 테스트 더블의 범주에 속하지만, 그 목적과 구현 방식에서 미묘한 차이가 있다. 스텁은 상태를 검증하기 위한 입력을 제공하는 데 주로 사용되고, 모의 객체는 객체 간의 상호작용(행위)이 예상대로 이루어졌는지를 검증하는 데 초점을 맞춘다.

테스트 더블은 소프트웨어 테스트를 수행할 때, 실제 구현체를 사용하기 어려운 경우 이를 대신하여 테스트를 가능하게 하는 객체나 모듈을 총칭하는 용어이다. 이 개념은 영화 산업에서 위험한 장면을 대신하는 스턴트 더블에서 유래하였다. 테스트 더블은 테스트 대상 코드가 의존하는 외부 컴포넌트나 아직 개발되지 않은 부분을 격리시키는 데 핵심적인 역할을 하며, 이를 통해 테스트의 속도, 안정성, 집중도를 높일 수 있다.

테스트 더블에는 여러 종류가 있으며, 각각의 용도와 동작 방식이 다르다. 대표적인 종류로는 미리 정의된 값을 반환하기만 하는 더미 객체, 실제 객체를 단순화한 버전인 페이크 객체, 호출 내역을 기록하는 스파이, 호출에 대한 기대 사항을 설정하고 검증하는 모의 객체 등이 있다. 본 문서에서 다루는 스텁은 이 테스트 더블의 한 종류로, 주로 특정 호출에 대해 하드코딩된 응답을 제공하는 단순한 형태이다.

테스트 더블을 효과적으로 사용하기 위해서는 각 유형의 차이점과 적절한 적용 시기를 이해하는 것이 중요하다. 예를 들어, 단위 테스트에서는 외부 데이터베이스나 네트워크 서비스에 의존하지 않도록 하기 위해 스텁이나 모의 객체를 사용하는 것이 일반적이다. 반면, 통합 테스트에서는 실제 시스템에 더 가까운 페이크 객체를 사용하기도 한다. 이러한 접근법은 테스트 주도 개발 및 애자일 개발 방법론에서 코드의 품질과 유연성을 보장하는 데 널리 활용된다.

페이크 객체는 테스트 더블의 한 유형으로, 실제 구현체와 유사하게 동작하지만 단순화된 버전을 제공하는 객체이다. 스텁이 단순히 미리 정의된 값을 반환하는 데 그친다면, 페이크 객체는 실제 객체와 동일한 인터페이스를 가지며 일부 내부 로직을 포함하여 실제처럼 동작한다. 그러나 실제 운영 환경에서 사용하기에는 부족한 부분이 있거나, 속도나 간편함을 위해 단순화된 구현을 사용한다. 예를 들어, 실제 데이터베이스 대신 메모리 상의 간단한 컬렉션을 사용하여 데이터를 저장하고 조회하는 객체가 페이크 객체에 해당한다.

이 객체의 주요 목적은 테스트나 개발 과정에서 외부 시스템에 대한 의존성을 제거하고 통제된 환경을 제공하는 데 있다. 실제 데이터베이스 서버나 외부 API를 사용하면 설정이 복잡하고 실행 속도가 느리며 네트워크 상태에 의존적일 수 있다. 페이크 객체를 사용하면 이러한 외부 의존 없이도 애플리케이션의 핵심 로직을 빠르고 안정적으로 검증할 수 있다. 또한, 아직 개발이 완료되지 않은 모듈과의 협업이 필요할 때 그 자리를 임시로 채우는 용도로도 활용된다.

페이크 객체는 모의 객체와 종종 비교된다. 모의 객체는 테스트 중에 객체가 어떻게 호출되었는지(어떤 메서드가, 몇 번 호출되었는지 등)를 검증하는 데 중점을 둔다. 반면 페이크 객체의 목적은 행위 검증이 아닌, 실제 객체의 기능을 대체하여 테스트를 수행할 수 있게 하는 것이다. 따라서 페이크 객체는 단순한 스텁보다는 복잡하고, 행위를 검증하는 모의 객체보다는 기능 제공에 초점을 맞춘다.

일반적인 사용 예시로는, 실제 이메일 발송 서비스 대신 콘솔에 로그만 출력하는 페이크 메일 서비스, 또는 복잡한 암호화 알고리즘 대신 단순한 문자열 변환을 수행하는 페이크 암호화 모듈을 들 수 있다. 이를 통해 개발자는 핵심 비즈니스 로직에 집중하면서도, 외부 시스템과의 통합이 준비될 때까지 효율적으로 작업을 진행할 수 있다.