End-to-end testing: honorarium flow and accounting export

epic-travel-expense-registration-org-extensions-task-008 — Write integration and widget tests covering the full driver honorarium flow: feature-flag guard renders form only for Blindeforbundet, rate guidance is displayed, submission is blocked until declaration is acknowledged, honorarium record is persisted with correct timestamps. Write integration tests for the AccountingIntegrationClient covering field mapping correctness for both Xledger and Dynamics adapters, retry behaviour on 5xx responses, double-export guard prevents duplicate submissions, and audit records are created for every attempt. Use mock HTTP adapters to simulate accounting system responses.

medium priority medium complexity testing pending testing specialist Tier 4

Acceptance Criteria

Widget test: DriverHonorariumForm is absent from widget tree when driver feature flag is inactive for a non-Blindeforbundet organisation

Widget test: DriverHonorariumForm is present and shows rate guidance when feature flag is active for Blindeforbundet

Widget test: submit button remains disabled when acknowledgement checkbox is unchecked

Widget test: submit button becomes enabled after user checks the acknowledgement checkbox

Integration test: on successful form submission, a honorarium record is inserted in the database with correct peer_mentor_id, amount, activity_id, and acknowledged_at timestamp

Integration test: declaration_acknowledgement record is created with fully_scrolled=true only when user has scrolled to the bottom of the declaration panel

Integration test (Deno): XledgerExporter maps amount, account code, cost centre, and VAT fields correctly for a representative Blindeforbundet expense record

Integration test (Deno): DynamicsExporter maps equivalent fields correctly for a representative HLF expense record

Integration test (Deno): retry logic fires on mocked 500 response and succeeds on the second attempt

Integration test (Deno): retry exhaustion after max_attempts results in a terminal failure record in export_runs

Integration test (Deno): double-export guard prevents resubmission of claim IDs already present in a successful export_runs record

Integration test (Deno): export_runs audit record is created for every export attempt, including failed attempts

All tests pass in CI (GitHub Actions or equivalent) without requiring live Xledger or Dynamics endpoints

Test coverage for driver honorarium flow (widget + BLoC) is at or above 80% line coverage

Technical Requirements

frameworks

Flutter

BLoC

flutter_test

Supabase Edge Functions (Deno)

apis

Supabase PostgreSQL 15 (local dev instance)

Xledger REST API (mocked)

Microsoft Dynamics 365 REST API (mocked)

data models

confidentiality_declaration

declaration_acknowledgement

activity

activity_type

performance requirements

Full widget test suite must complete within 60 seconds

Deno integration test suite must complete within 120 seconds using mock HTTP

security requirements

No real Xledger or Dynamics credentials used in tests — all tests use mock credentials and mock HTTP interceptors

Test fixtures must not contain real personal data — use synthetic UUIDs and amounts

ui components

DriverHonorariumForm (under test)

DeclarationScrollPanel (under test)

AppCheckbox (under test)

Execution Context

Execution Tier

Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

View Full Execution Plan

Implementation Notes

For widget tests, set up a BlocProvider wrapping the widget under test with a mocked DriverHonorariumService injected via constructor. Use tester.pumpWidget and pump() for async operations. For scroll-to-bottom test, use tester.drag to simulate scroll and verify fully_scrolled state in BLoC. For Deno tests, create a MockFetchAdapter class that queues predefined responses (200, 500, etc.) and records all outbound requests for assertion.

For the double-export guard test, pre-insert a successful export_runs record in the local Supabase test database before running the guard assertion. Use Supabase local dev (supabase start) for database integration tests. Document any test data setup/teardown in a dedicated test README section.

Testing Requirements

Test types: Flutter widget tests (flutter_test), Flutter integration tests (integration_test package), Deno unit/integration tests. Use mocktail for mocking DriverHonorariumService and Supabase client in Flutter tests. Use Deno's built-in fetch mock (or a lightweight mock HTTP server) for Edge Function tests. Organise tests into: /test/widget/driver_honorarium_form_test.dart, /test/integration/driver_honorarium_flow_test.dart, /edge_functions/test/accounting_integration_test.ts.

All tests must be deterministic (no flakiness from real network or time-dependent behaviour — mock DateTime.now() and HTTP). Run via flutter test and deno test in CI.

Component

Driver Honorarium Service

service medium

Dependencies (2)

Add exponential-backoff retry logic to the AccountingIntegrationClient for transient HTTP failures, with a configurable maximum attempt count. Implement an export_runs audit table recording each export attempt: organisation, batch of claim IDs, HTTP status, error message, and timestamp. Build a double-export guard that checks the audit table before submission to prevent duplicate entries in the accounting systems. Expose an export status query method so the coordinator UI can display last-run results. epic-travel-expense-registration-org-extensions-task-007 Extend the DriverHonorariumForm to present the linked confidentiality declaration text, rendered in a scrollable read-only panel. Add an acknowledgement checkbox with accessible semantics label. Implement submission-blocking logic that prevents the parent expense form from progressing to submit until the checkbox is checked. Record the acknowledgement timestamp via DriverHonorariumService on checkbox activation. Declaration text must be sourced from org configuration, not hardcoded. epic-travel-expense-registration-org-extensions-task-004

Epic Risks (3)

high impact high prob integration

The Dynamics portal (HLF) and Xledger (Blindeforbundet) APIs have organisation-managed API contracts that may change without notice. Field mapping requirements, authentication flows, and export formats are not fully documented and may only be clarified during integration testing.

Mitigation & Contingency

Mitigation: Engage HLF and Blindeforbundet technical contacts early to obtain API documentation, sandbox credentials, and example payloads before implementation starts. Design the accounting integration client as a thin adapter layer with organisation-specific mappers so that field mapping changes require only mapper updates, not core client changes.

Contingency: If API documentation is unavailable or the API is unstable during Phase 3, implement a CSV/JSON file export as an interim deliverable. Coordinators can manually upload the file to their respective accounting systems until the live API integration is completed.

high impact medium prob scope

The confidentiality declaration for Blindeforbundet drivers may have specific legal requirements around content, format, wording, and record-keeping that are not yet specified. Implementing the wrong declaration flow could expose Blindeforbundet to compliance risk.

Mitigation & Contingency

Mitigation: Treat the declaration content and acknowledgement flow as a Blindeforbundet-controlled configuration, not hardcoded text. Implement the declaration as a templated document fetched from Supabase and reviewed by Blindeforbundet before any production deployment. Obtain written sign-off on the declaration text and acknowledgement mechanism before the epic is considered complete.

Contingency: If legal requirements cannot be confirmed in time for the sprint, deliver the driver honorarium form without the confidentiality declaration and gate the entire driver feature behind its feature flag. The declaration can be added in a follow-up sprint once requirements are confirmed, without blocking other feature delivery.

high impact medium prob integration

If the accounting export can be triggered multiple times for the same approved claims batch, duplicate records may be created in Dynamics or Xledger, causing accounting reconciliation problems that are difficult to reverse.

Mitigation & Contingency

Mitigation: Implement idempotent export runs: each export batch is assigned a unique run ID stored in the database. The accounting integration client checks for an existing successful export run for the same claim IDs before submitting. Approved claims that have been exported are marked with exported_at timestamp to prevent re-export.

Contingency: If duplicate exports occur despite idempotency checks (e.g. network failure after API success but before local confirmation), provide coordinators with an export history panel showing run IDs and timestamps. Implement a reconciliation endpoint that can query the accounting system for existing records before re-submitting flagged claims.

Quick Links

All Tasks Execution Plan