Feature #3515
open[drcarrot-mobile-inpatient-list-v3] 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 Inpatient list 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 Inpatient list module:
- Service:
src/services/<module_name>.tsor equivalent - Hooks:
src/hooks/<module_name>/** - Screens:
src/screens/<module_name>/** - Sections/components:
src/sections/<module_name>/**orsrc/components/<module_name>/** - Utils:
src/utils/<module_name>/** - Redux slice, if present:
src/store/slices/<module_name>.ts - Storybook stories, if present:
src/sections/<module_name>/**/*.stories.tsxsrc/components/<module_name>/**/*.stories.tsx
- Tracing, if present:
src/traces/<module_name>.ts
Storybook Tests¶
If Inpatient list contains .stories.tsx files:
- Create tests under:
src/__tests__/sections/<module_name>/<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/<module_name>.ts exists, create:
src/__tests__/traces/<module_name>.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 <module_name> 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, if applicable
- Report generation/download/sequence behavior, if applicable
@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 <module_name> 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: