Feature #3392
open[drcarrot-mobile-payments] orchestration run
0%
Description
Orchestration run tracking ticket. Not the real implementation ticket — this exists only so the live timing table has somewhere to post from step 1 onward. The real backend/mobile/web ticket(s) are created and cross-linked here once the run reaches that step.
Requirement:
"Write comprehensive Jest unit tests for the Payments module to achieve full code coverage.
Target Coverage¶
- Statements: 90%+
- Branches: 85%+
- Functions: 90%+
- Lines: 90%+
These targets must match the repo's global coverage thresholds in jest.config.js.
Scope¶
Cover every layer that exists for the Payments module:
-
Service:
src/services/PaymentsService.tsor equivalent -
Hooks:
src/hooks/payments/** -
Screens:
src/screens/Payments/** -
Sections/components:
src/sections/payments/**orsrc/components/payments/** -
Utils:
src/utils/payments/** -
Redux slice, if present:
src/store/slices/paymentsSlice.ts -
Storybook stories, if present:
src/sections/payments/**/*.stories.tsxsrc/components/payments/**/*.stories.tsx
-
Tracing, if present:
src/traces/payments.ts
Storybook Tests¶
If Payments contains .stories.tsx files:
- Create tests under:
src/__tests__/sections/payments/<Component>.stories.test.tsx - Import every named story export.
- Render every exported story using the same RTL helpers already used elsewhere in the project.
- Verify every story renders without crashing.
- Verify story args/controls match the component prop types.
- Tag Storybook tests with
@p2, unless the story is the only meaningful coverage for a component, in which case use@p1.
Trace Tests¶
If src/traces/payments.ts exists, create:
src/__tests__/traces/payments.test.ts
Mock src/utils/otel.ts exactly as existing trace tests do.
For every exported span-builder/helper, verify:
- Span name
- Span attributes
- Successful execution
status=ERRORon failure- Error recording on failure
Use:
@p1for successful execution tests@p2for failure-path tests
Test Priority Tags¶
Every it() / test() title must start with @p1, @p2, or @p3.
@p1 — Critical Path¶
Cover:
- Component/hook renders or initializes without crashing
- Empty/loading/no-records states
- Core CRUD happy paths
- Primary API success and failure handling
- Required-field validation
- Status/data mapping
- Auth/permission gates that block access
@p2 — Important Secondary Behavior¶
Cover:
- Search/sort/filter interactions
- API parameter wiring
- Pagination
- Dialog open/close/cancel
- Permission-based UI hiding
- Refresh/pull-to-refresh
- Secondary API errors
- File upload validation
- Sequence/code generation
@p3 — Edge Cases¶
Cover:
null/undefined/ boolean coercion- Malformed or partial API responses
- Invalid/boundary dates
- Non-matching selections
- Whitespace-only/empty search
- Independent toggle states
Test Implementation Requirements¶
-
Inspect all Payments source files line by line before writing tests.
-
Exercise every:
- Conditional
- Ternary
- Optional-chaining fallback
- Switch/case branch
- Validation branch
- Success path
- Error path
-
Use the existing mock boilerplate patterns in this repo.
Use these reference tests:
src/__tests__/services/ProcurementsService.test.tssrc/__tests__/hooks/procurement/usePurchaseBill.test.ts
-
Mock the following exactly as the reference tests do:
ApiClientAsyncStorageLogger- Navigation
Do not introduce a new mocking approach.
-
Organize tests using
describe()blocks by behavior area:- Core behavior
- Search & sort
- Pagination
- Permissions
- Error handling
- Edge cases
-
Do not use
anyor other explicit unsafe types in test code. -
Do not add:
- Skipped tests
- Pending tests
- Unnecessary snapshot tests
-
Do not modify production/business logic.
-
Only add or update the required Jest test files and test configuration if absolutely necessary for priority filtering.
-
Do not create unnecessary documentation.
Coverage Validation¶
After implementing the tests, run:
Check the coverage for:
- Statements: 90%+
- Branches: 85%+
- Functions: 90%+
- Lines: 90%+
If coverage is below the required thresholds, inspect the uncovered lines/branches and add the required tests. Continue iterating until the thresholds are met.
Priority Validation¶
Then run:
npm run test:p1 -- <Payments-test-path>
npm run test:p2 -- <Payments-test-path>
npm run test:p3 -- <Payments-test-path>
Confirm that:
- The priority filters select the intended tests.
- All selected tests pass.
- Every test has the correct
@p1,@p2, or@p3tag.
Expected Test Files¶
Create one test file per Payments source file, following the existing __tests__ folder structure.
Create Storybook test files only when Payments stories exist.
Create the trace test file only when src/traces/payments.ts exists.
Do not create tests for files that do not exist.
Expected Output¶
Finally, provide a short summary table:
| File | P1 Count | P2 Count | P3 Count | Coverage |
|---|---|---|---|---|
| Payments test file | ||||
| ... | ||||
| Total |
Also provide a brief confirmation that:
- Coverage thresholds were met.
- P1 tests passed.
- P2 tests passed.
- P3 tests passed.
- No production/business logic was modified.
"