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 Laboratory 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 Laboratory module:

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

Hooks: src/hooks/laboratory/**

Screens: src/screens/Laboratory/**

Sections/components: src/sections/laboratory/ or src/components/laboratory/

Utils: src/utils/laboratory/**

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

Storybook stories (if present): src/sections/laboratory/*/.stories.tsx or

src/components/laboratory/*/.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/laboratory.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 Laboratory 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 Laboratory 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 Laboratory contains .stories.tsx files, create

render tests under:

src/tests/sections/laboratory/.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 Laboratory contains:

src/traces/laboratory.ts

create:

src/tests/traces/laboratory.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 Laboratory test coverage.

Output:

One test file per Laboratory source file following the existing tests

folder structure.

Storybook test files only when Laboratory stories exist.

Trace test file only when Laboratory traces exist.

A short summary table showing:

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