Project

General

Profile

Actions

Feature #3392

open
BA

[drcarrot-mobile-payments] orchestration run

Feature #3392: [drcarrot-mobile-payments] 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/16/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 Payments 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 Payments module:

  • Service: src/services/PaymentsService.ts or equivalent

  • Hooks: src/hooks/payments/**

  • Screens: src/screens/Payments/**

  • Sections/components: src/sections/payments/** or src/components/payments/**

  • Utils: src/utils/payments/**

  • Redux slice, if present: src/store/slices/paymentsSlice.ts

  • Storybook stories, if present:

    • src/sections/payments/**/*.stories.tsx
    • src/components/payments/**/*.stories.tsx
  • Tracing, if present: src/traces/payments.ts

Storybook Tests

If Payments contains .stories.tsx files:

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

src/__tests__/traces/payments.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 CRUD 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
  • Sequence/code generation

@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 Payments 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
  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
  2. Do not use any or other explicit unsafe types in test code.

  3. Do not add:

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

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

  6. Do not create unnecessary documentation.

Coverage Validation

After implementing the tests, run:

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

Check the coverage for:

  • Statements: 90%+
  • Branches: 85%+
  • Functions: 90%+
  • Lines: 90%+

If coverage is below the required thresholds, inspect the uncovered lines/branches and add the required tests. Continue iterating until the thresholds are met.

Priority Validation

Then run:

npm run test:p1 -- <Payments-test-path>
npm run test:p2 -- <Payments-test-path>
npm run test:p3 -- <Payments-test-path>

Confirm that:

  • The priority filters select the intended tests.
  • All selected tests pass.
  • Every test has the correct @p1, @p2, or @p3 tag.

Expected Test Files

Create one test file per Payments source file, following the existing __tests__ folder structure.

Create Storybook test files only when Payments stories exist.

Create the trace test file only when src/traces/payments.ts exists.

Do not create tests for files that do not exist.

Expected Output

Finally, provide a short summary table:

File P1 Count P2 Count P3 Count Coverage
Payments test file
...
Total

Also provide a brief confirmation that:

  • Coverage thresholds were met.
  • P1 tests passed.
  • P2 tests passed.
  • P3 tests passed.
  • No production/business logic was modified.
    "
Actions

Also available in: PDF Atom