NestJS 테스트와 CI

단위 테스트 작성과 모킹: Jest 검증과 mock 계약 점검

단위 테스트는 함수를 호출해 보는 절차가 아니라 규칙을 작게 고정하는 장치입니다. mock은 편의가 아니라 경계 계약으로 다뤄야 합니다.

business rule provider method mock contract resolve / reject edge input null / exception assertion Given / Then 거짓 실패와 누락 경로 분리
01

Provider 규칙과 assertion 단위

service method의 business rule, edge input, 예외 경로를 작게 나누고 Jest assertion은 결과와 호출 계약만 확인합니다.

규칙 단위
02

TestingModule과 mock provider

TestingModule에서 외부 repository/client를 mock provider로 바꾸되 실제 method 이름과 reject/resolve 형태는 유지합니다.

mock 계약
03

구현 세부에 묶인 mock

private 흐름이나 호출 순서만 검증하면 리팩터링 때 거짓 실패가 늘고 규칙 누락은 놓칩니다.

거짓 실패
04

Jest 실패 로그와 assertion 근거

테스트 이름, Given/When/Then 데이터, mock contract, assertion 근거를 남겨 실패 위치를 빠르게 좁힙니다.

실패 근거
책임
단위 테스트는 provider의 business rule을 가장 작은 입력으로 검증한다 Jest assertion은 return value, thrown exception, dependency 호출 계약을 확인하고 HTTP 응답 모양은 E2E로 넘깁니다.
규칙
경계
mock provider는 실제 dependency의 method 계약을 그대로 따라야 한다 TestingModule override에서 repository/client의 resolve, reject, side effect를 명시해 과한 mock이 규칙을 숨기지 않게 합니다.
mock
Edge 입력
edge input과 예외 경로는 성공 케이스와 같은 이름으로 둔다 null, empty, 권한 없음, dependency 실패를 별도 test case로 두어 coverage 숫자가 아니라 규칙 누락을 잡습니다.
edge

Jest 단위 테스트와 mock 계약 검증 지점

Jest assertion provider method 입력, mock provider 응답, Jest assertion이 하나의 business rule을 직접 설명하는지 확인합니다.
Exception assertion 구현 세부 호출 순서만 검증하면 리팩터링 때 거짓 실패가 늘고 예외 경로 누락을 놓칩니다.
Coverage diff Jest 실패 메시지, mock contract, edge case 이름, coverage diff를 함께 남겨 변경된 규칙을 추적합니다.

Jest 단위 테스트 점검

질문: provider 규칙이 mock 없이도 설명되고 Jest assertion이 그 규칙을 직접 확인하는가
순서: service method 입력 고정 -> mock provider 계약 작성 -> success/exception assertion 분리
위험: dependency 호출 순서만 검증하면 구현을 바꿀 때 테스트는 깨지지만 실제 business rule 누락은 잡지 못합니다.