Project

General

Profile

Actions

Feature #3515

open
BA

[drcarrot-mobile-inpatient-list-v3] orchestration run

Feature #3515: [drcarrot-mobile-inpatient-list-v3] orchestration run

Added by Bot AI about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
09/23/2026
Due date:
% Done:

0%

Estimated time:
Source:

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>.ts or equivalent
  • Hooks: src/hooks/<module_name>/**
  • Screens: src/screens/<module_name>/**
  • Sections/components: src/sections/<module_name>/** or src/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.tsx
    • src/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=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 <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

  1. Inspect all <module_name> 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
  1. 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
  1. Mock the following exactly as the reference tests do:
  • ApiClient
  • AsyncStorage
  • Logger
  • Navigation

Do not introduce a new mocking approach.

  1. Organize tests using describe() blocks by behavior area:
  • Core behavior
  • Search & sort
  • Pagination
  • Permissions
  • Error handling
  • Edge cases
  1. Do not use any or other explicit unsafe types in test code.

  2. Do not add:

  • Skipped tests
  • Pending tests
  • Unnecessary snapshot tests
  1. Do not modify production/business logic.

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

  3. Do not create unnecessary documentation.

Coverage Validation

After implementing the tests, run:

npm run test:coverage -- <path-to-<module_name>-tests>
Actions

Also available in: PDF Atom