src/escrow/escrow.controller.spec.ts is titled describe('EscrowController (#19 metadata leak)', ...) and its four tests all verify one thing: that metadata never appears in fund/findOne/release/refund's response bodies. It does not test that each handler calls EscrowService with the arguments derived from the request (path param + DTO), that splitRelease is wired correctly, or that the @Idempotent(...) decorator on each route actually attaches IdempotencyInterceptor in the real DI graph (as opposed to being verified only indirectly, at the interceptor's own unit-test level).
As the sole controller-level spec in the entire repository, its narrow scope creates a false impression of controller coverage: a reviewer skimming the file list sees "escrow has a controller spec, others don't" and might reasonably (incorrectly) assume escrow's controller-level behavior is well-covered.
Fix: broaden this spec (or add a sibling one) to assert each handler forwards the correct arguments to EscrowService, and add an integration-style check that @Idempotent-decorated routes actually require the Idempotency-Key header end-to-end through the real Nest module (not just via IdempotencyInterceptor's own isolated unit tests).
src/escrow/escrow.controller.spec.ts is titled
describe('EscrowController (#19 metadata leak)', ...)and its four tests all verify one thing: thatmetadatanever appears infund/findOne/release/refund's response bodies. It does not test that each handler callsEscrowServicewith the arguments derived from the request (path param + DTO), thatsplitReleaseis wired correctly, or that the@Idempotent(...)decorator on each route actually attachesIdempotencyInterceptorin the real DI graph (as opposed to being verified only indirectly, at the interceptor's own unit-test level).As the sole controller-level spec in the entire repository, its narrow scope creates a false impression of controller coverage: a reviewer skimming the file list sees "escrow has a controller spec, others don't" and might reasonably (incorrectly) assume escrow's controller-level behavior is well-covered.
Fix: broaden this spec (or add a sibling one) to assert each handler forwards the correct arguments to
EscrowService, and add an integration-style check that@Idempotent-decorated routes actually require theIdempotency-Keyheader end-to-end through the real Nest module (not just viaIdempotencyInterceptor's own isolated unit tests).