Orchestration Runs

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 module to achieve full code coverage

(target: Stmt 90%+ | Branch 85%+ | Fn 90%+ | Ln 90%+, matching this repo's global coverage thresholds in jest.config.js).

Scope — cover every layer that exists for the Inpatient module:

Service layer: src/services/InpatientService.ts (or equivalent)

Hooks: src/hooks/inpatient/**

Screens: src/screens/Inpatient/**

Sections/components: src/sections/inpatient/ or src/components/inpatient/

Utils: src/utils/inpatient/**

Redux slice (if present): src/store/slices/inpatientSlice.ts

Storybook stories (if present): src/sections/inpatient//.stories.tsx or src/components/inpatient//.stories.tsx — verify each exported story renders without crashing and that its args/controls match the component's prop types.

Tracing (if present): src/traces/inpatient.ts — cover every exported span-builder/helper, asserting span name, attributes, and status are set correctly for success and error paths.

For EVERY test, prefix the it()/test() title with a priority tag: @p1, @p2, or @p3.

Priority rubric:

@p1 — Critical path, must-pass-before-merge:

Component/hook renders or initializes without crashing

Empty state / loading state / "no records" rendering

Core CRUD happy paths: create, edit, delete succeed and update state correctly

Primary API success AND failure handling

Required-field validation blocking submit

Status/data mapping logic

Auth/permission gates that block access entirely

@p2 — Important but secondary behavior:

Search, sort, filter interactions and API parameter wiring

Pagination

Dialog open/close/cancel flows

Permission-based UI hiding

Refresh / pull-to-refresh flows

Secondary API error handling

File upload validation

Sequence/code generation logic

@p3 — Edge cases, rare inputs:

null/undefined/boolean coercion

Malformed or partially missing API responses

Invalid date strings / boundary dates

Non-matching selections

Whitespace-only or empty-string search input

Independent toggle states

Requirements:

Use the existing mock boilerplate patterns already established in this repo.

Use these as references:

• src/tests/services/ProcurementsService.test.ts
• src/tests/hooks/procurement/usePurchaseBill.test.ts

Mock ApiClient, AsyncStorage, Logger, and navigation exactly as done in those reference files. Do not introduce a new mocking approach.

Group tests with describe() blocks by behavior area:

• Core behavior
• Search & sort
• Pagination
• Permissions
• Error handling
• Edge cases

Check the Inpatient source files line by line.

Every conditional, ternary, optional chaining fallback, switch/case branch, validation branch, success path, and error path must be exercised.

Do not use any types in test code.

Do not add skipped/pending tests.

Do not add snapshot tests unless there is no meaningful interactive behavior to assert.

After writing the Inpatient tests, run:

npm run test:coverage --

Iterate on the tests until the required coverage thresholds are met.

Then run:

npm run test:p1 --

npm run test:p2 --

npm run test:p3 --

Confirm that the priority filters correctly select the intended tests and that all selected tests pass.

For Storybook stories, if Inpatient contains .stories.tsx files, create render tests under:

src/tests/sections/inpatient/.stories.test.tsx

Import every named story export and render it using the same RTL helpers already used elsewhere in the project.

Tag Storybook tests @p2 unless the story is the only meaningful coverage for a component, in which case use @p1.

For trace helpers, if Inpatient contains:

src/traces/inpatient.ts

create:

src/tests/traces/inpatient.test.ts

Mock src/utils/otel.ts exactly as existing trace tests do.

Assert:

• Span name
• Span attributes
• Successful execution
• status=ERROR and error recording on failure

Tag success-path tests @p1 and failure-path tests @p2.

Do not modify production/business logic.

Only add or update the required Jest test files and test configuration if absolutely necessary for the priority filtering.

Do not create unnecessary documentation.

Focus on implementing and validating the Inpatient test coverage.

Output:

One test file per Inpatient source file following the existing tests folder structure.

Storybook test files only when Inpatient stories exist.

Trace test file only when Inpatient traces exist.

A short summary table showing:

File | P1 Count | P2 Count | P3 Count | Coverage"