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

• Service: src/services/ReportsService.ts or equivalent
• Hooks: src/hooks/reports/**
• Screens: src/screens/Reports/**
• Sections/components: src/sections/reports/** or src/components/reports/**
• Utils: src/utils/reports/**
• Redux slice, if present: src/store/slices/reportsSlice.ts
• Storybook stories, if present:
  • src/sections/reports/**/*.stories.tsx
  • src/components/reports/**/*.stories.tsx
• Tracing, if present: src/traces/reports.ts

Storybook Tests¶

If Reports contains .stories.tsx files:

• Create tests under:
  src/__tests__/sections/reports/<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/reports.ts exists, create:

src/__tests__/traces/reports.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=ERROR on failure
• Error recording on failure

Use:

• @p1 for successful execution tests
• @p2 for 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 Reports 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¶

1. Inspect all Reports source files line by line before writing tests.

2. Exercise every:

• Conditional
• Ternary
• Optional-chaining fallback
• Switch/case branch
• Validation branch
• Success path
• Error path

3. Use the existing mock boilerplate patterns in this repo.

Use these reference tests:

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

4. Mock the following exactly as the reference tests do:

• ApiClient
• AsyncStorage
• Logger
• Navigation

Do not introduce a new mocking approach.

5. Organize tests using describe() blocks by behavior area:

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

6. Do not use any or other explicit unsafe types in test code.

7. Do not add:

• Skipped tests
• Pending tests
• Unnecessary snapshot tests

8. Do not modify production/business logic.

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

10. Do not create unnecessary documentation.

Coverage Validation¶

After implementing the tests, run:

npm run test:coverage -- <path-to-Reports-tests>