📌 Description
SettlementDetailPage (src/app/settlements/[id]/page.tsx) contains real branching logic with no test coverage at all: it calls notFound() when the route param isn't a finite number (if (!Number.isFinite(numericId)) { notFound(); }), and separately calls notFound() when fetchSettlement throws an ApiRequestError with status === 404 (re-throwing any other error). Unlike its sibling anchors/[id]/error.test.tsx/anchors/[id]/loading.test.tsx, there is no settlements/[id]/page.test.tsx (or equivalent) exercising either of these branches, so a regression in the id-parsing or 404-mapping logic would go unnoticed by the test suite.
🧩 Requirements and context
- Add test coverage for
SettlementDetailPage's three meaningful branches: (1) a non-numeric id param triggers notFound(), (2) fetchSettlement throwing an ApiRequestError with status === 404 triggers notFound(), and (3) a successful fetch renders SettlementDetail with the fetched data as initialData.
- Mock
next/navigation's notFound (it throws in the real Next.js runtime to halt rendering) and src/lib/settlementsApi's fetchSettlement following the conventions already used in the existing error.test.tsx/loading.test.tsx files for this route segment.
- No production code changes are expected; this is purely closing a test-coverage gap on already-shipped logic.
🛠️ Suggested execution
- Create
src/app/settlements/[id]/page.test.tsx, awaiting the async Server Component directly (as is already done for other async Server Component tests in this codebase, if any precedent exists) or rendering it via a small test harness, mocking fetchSettlement and next/navigation's notFound.
- Cover the three branches described above, asserting
notFound() is called (or not) as appropriate and that a successful fetch's data reaches SettlementDetail.
✅ Acceptance criteria
🔒 Security notes
No new attack surface; a test-coverage task on already-shipped routing/error-mapping logic.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
SettlementDetailPage(src/app/settlements/[id]/page.tsx) contains real branching logic with no test coverage at all: it callsnotFound()when the route param isn't a finite number (if (!Number.isFinite(numericId)) { notFound(); }), and separately callsnotFound()whenfetchSettlementthrows anApiRequestErrorwithstatus === 404(re-throwing any other error). Unlike its siblinganchors/[id]/error.test.tsx/anchors/[id]/loading.test.tsx, there is nosettlements/[id]/page.test.tsx(or equivalent) exercising either of these branches, so a regression in the id-parsing or 404-mapping logic would go unnoticed by the test suite.🧩 Requirements and context
SettlementDetailPage's three meaningful branches: (1) a non-numericidparam triggersnotFound(), (2)fetchSettlementthrowing anApiRequestErrorwithstatus === 404triggersnotFound(), and (3) a successful fetch rendersSettlementDetailwith the fetched data asinitialData.next/navigation'snotFound(it throws in the real Next.js runtime to halt rendering) andsrc/lib/settlementsApi'sfetchSettlementfollowing the conventions already used in the existingerror.test.tsx/loading.test.tsxfiles for this route segment.🛠️ Suggested execution
src/app/settlements/[id]/page.test.tsx, awaiting the async Server Component directly (as is already done for other async Server Component tests in this codebase, if any precedent exists) or rendering it via a small test harness, mockingfetchSettlementandnext/navigation'snotFound.notFound()is called (or not) as appropriate and that a successful fetch's data reachesSettlementDetail.✅ Acceptance criteria
notFound()fires.404ApiRequestErrorfromfetchSettlementis covered by a test assertingnotFound()fires.🔒 Security notes
No new attack surface; a test-coverage task on already-shipped routing/error-mapping logic.
📋 Guidelines