모킹 (Mocking)

모킹(Mocking)은 테스트에서 실제 의존 대상을 대역으로 바꾸고, 그 대역의 응답이나 호출 내역을 제어·검증하는 기법입니다. 외부 API나 저장 장치의 상태에 덜 좌우되면서 특정 코드의 판단을 살필 때 씁니다. 대역이 성공 값을 돌려주거나 오류를 일으키게 하고, 어떤 인수로 몇 번 호출됐는지 확인합니다.

대역의 응답과 호출 기록

주문 코드가 결제 API를 부르면 네트워크 지연이나 결제 계정 상태가 테스트 결과에 섞입니다. 결제 부분을 같은 인터페이스의 대역으로 교체하면 승인과 거절 응답을 정해 주문 상태 변화를 확인합니다. GoogleTest의 gMock 안내는 목을 실제 객체와 같은 인터페이스를 가지면서 호출 방식과 동작을 지정하는 객체로 설명합니다. 테스트가 직접 통제하는 범위가 어디까지인지 정하는 과정입니다.

Python의 unittest.mock 문서는 반환값 설정과 호출 인수 확인, 예외 발생 설정을 함께 제공합니다. 결제 거절 뒤 배송 요청이 나가지 않았는지처럼 결과값만으로 드러나지 않는 동작도 확인할 수 있습니다. 다만 실패 응답을 만들었다는 사실과 그 실패를 처리하는 코드가 올바르다는 판정은 별개입니다. 대역 설정에 더해 실제로 검사할 결과나 호출 조건이 있어야 테스트가 오류를 발견합니다.

대체 위치도 실행 경로와 맞아야 합니다. 모듈이 이미 가져온 함수를 다른 곳에서 교체하면 테스트 대상은 원래 함수를 계속 참조할 수 있습니다. Python 문서는 객체가 조회되는 이름 공간에서 패치하도록 설명합니다. 예상과 달리 외부 호출이 발생했다면 대역의 반환값부터 바꾸기보다, 테스트 대상이 어떤 이름을 통해 의존 대상에 접근하는지 확인하는 편이 원인 분리에 도움이 됩니다.

목·스텁·페이크의 구분

목(mock)과 스텁(stub)은 테스트 대역을 분류하는 용어입니다. 마틴 파울러의 목과 스텁 비교에서 스텁은 미리 정한 응답을 제공하고, 목은 기대하는 호출을 기준으로 상호작용을 검증합니다. 잔액 조회에 정해진 숫자를 돌려줘 주문의 최종 상태를 살피면 스텁의 역할입니다. 같은 조회가 지정한 계정으로 한 번 호출됐는지를 판정에 포함하면 호출 행위까지 검증합니다.

하나의 도구가 두 역할을 모두 지원하기도 합니다. 라이브러리의 클래스 이름이 Mock이라고 해서 모든 테스트가 호출 검증을 하는 것은 아닙니다. 반환값만 지정한 뒤 최종 결과를 검사할 수도 있습니다. 코드 리뷰에서는 도구 이름보다 무엇을 성공 조건으로 삼는지 살펴야 목과 스텁의 차이가 드러납니다. 호출 순서가 업무 규칙에 영향을 주지 않는다면 순서를 고정하는 검사가 필요하지 않을 수도 있습니다.

페이크(fake)는 축약된 동작 구현을 갖춘 대역입니다. GoogleTest의 대역 구분은 메모리 안에서 동작하는 파일 시스템을 예로 듭니다. 저장한 값을 나중에 읽게 하는 페이크는 호출마다 값을 지정하는 방식과 다릅니다. 실제 저장 장치의 권한·잠금·장애 동작까지 재현하는지는 구현 범위에 달려 있습니다. 목·스텁·페이크를 선택할 때는 검사하려는 동작과 대역이 생략하는 동작을 함께 봅니다.

검증 범위와 유지보수 비용

세부 호출을 모두 고정하면 내부 코드를 재구성했을 때 테스트가 함께 깨질 수 있습니다. 파울러의 구현 결합 설명은 호출 기대가 구현과 얽히는 문제를 다룹니다. 결제 중복 요청 금지는 관찰할 가치가 있는 동작이지만, 외부 결과에 영향이 없는 보조 함수 호출 순서는 다를 수 있습니다. 업무상 필요한 상호작용을 고르면 테스트 실패가 실제 동작 변화인지 내부 정리의 영향인지 구분하기 쉬워집니다.

대역은 실제 대상의 계약과 어긋날 수 있습니다. 실제 함수에서 사라진 인수를 목이 계속 허용하면 테스트가 통과해도 배포 뒤 호출이 실패합니다. Python의 자동 명세 기능은 실제 객체의 속성과 호출 형태를 따라 대역을 만들도록 지원합니다. 이 기능도 원격 서비스의 응답 의미나 배포 설정을 확인하지는 않습니다. 실제 시스템과 맞닿는 별도 테스트가 필요한 이유입니다.

모킹을 늘리기 전에는 외부 의존성이 실패 원인인지, 코드 자체의 입력과 출력만 검사해도 되는지 살핍니다. 대역의 설정이 테스트 본문보다 복잡해졌다면 하나의 코드가 너무 많은 협력 대상을 다루는지 검토할 수 있습니다. 테스트 뒤에는 패치와 호출 기록을 정리해 다음 테스트의 결과에 섞이지 않게 합니다. 같은 대역을 재사용할 때는 이전 호출 횟수와 응답 설정까지 재사용되는지 확인합니다.