Unit tests for ScenarioConfigurationManager

epic-scenario-based-follow-up-prompts-core-logic-task-010 — Write unit tests for ScenarioConfigurationManager covering: loading rules for a chapter with and without existing data, JSON schema validation accepting valid rules and rejecting malformed inputs, default template seeding when chapter has no rules, saveRule persisting via repository, and deleteRule removing the correct record. Use mock ScenarioRuleRepository. Test at least 15 distinct scenarios.

high priority medium complexity testing pending testing specialist Tier 3

Acceptance Criteria

At least 15 distinct test scenarios are implemented and all pass with flutter_test

loadRulesForChapter returns empty list when no rules exist for a given chapterId

loadRulesForChapter returns correct rules list when data exists for the given chapterId

JSON schema validation accepts a fully valid ScenarioRule object without throwing

JSON schema validation rejects a rule missing required fields and returns a descriptive error

JSON schema validation rejects a rule with an incorrect field type (e.g., string where int expected)

Default template seeding is triggered exactly once when a chapter has no existing rules

Seeded default templates match the predefined template definitions (correct scenario_type, trigger_conditions, prompt_content)

saveRule calls repository.save() with the exact ScenarioRule object provided

saveRule returns the persisted rule with an assigned rule_id

deleteRule calls repository.delete() with the correct rule_id

deleteRule does not affect other rules belonging to the same chapterId

All repository interactions use the mock ScenarioRuleRepository — no real Supabase calls occur

Tests are grouped by method name using group() blocks for readability

Each test has a descriptive name following the pattern: 'given [state], when [action], then [outcome]'

Technical Requirements

frameworks

Flutter

flutter_test

Riverpod

mockito or mocktail

data models

ScenarioRule

ScenarioRuleRepository

ScenarioConfigurationManager

performance requirements

All unit tests must complete in under 2 seconds total

No async delays beyond minimal Future.value() stubs

security requirements

Mock repository must not persist any data to disk or Supabase during tests

No real chapterId or user credentials used in test data — use synthetic IDs

Execution Context

Execution Tier

Tier 3

Tier 3 - 413 tasks

Can start after Tier 2 completes

View Full Execution Plan

Implementation Notes

ScenarioConfigurationManager should be instantiated with a mock ScenarioRuleRepository injected via constructor (not Riverpod provider) to keep unit tests isolated from the provider graph. Use mocktail's when().thenAnswer() pattern for async stubs. For JSON schema validation tests, define inline fixture maps directly in the test file — do not read from files to keep tests self-contained. Default template seeding logic should be tested by verifying repository.save() is called N times (one per default template) when loadRulesForChapter returns an empty list.

Use verify() to assert interaction counts. Avoid testing private methods directly — only test the public API surface.

Testing Requirements

Unit tests only using flutter_test. Use mocktail or mockito to mock ScenarioRuleRepository. Structure tests in a single file (scenario_configuration_manager_test.dart) with group() blocks per method under test. Cover: (1) loadRulesForChapter — empty state, populated state, multi-chapter isolation; (2) JSON schema validation — valid input, missing required field, wrong type, extra unknown field; (3) default template seeding — triggers on empty, does not re-seed when rules exist; (4) saveRule — delegates to repository with correct args, returns persisted rule; (5) deleteRule — correct ID forwarded, idempotent on non-existent ID.

All 15+ scenarios must be deterministic and not depend on execution order.

Component

Scenario Configuration Manager

service medium

Dependencies (1)

Build the ScenarioConfigurationManager service that provides chapter-level rule management. Implement loadRulesForChapter(), saveRule(rule), deleteRule(ruleId), validateRuleJson(json), and seedDefaultTemplates(chapterId). Validation uses the JSON schema from task-001. Default templates are seeded when a chapter has no rules. Depends on ScenarioRuleRepository. epic-scenario-based-follow-up-prompts-core-logic-task-004

Epic Risks (2)

high impact medium prob scope

The Rule Engine must support a flexible JSON rule schema that can express compound conditions (e.g., contact_type AND wellbeing_flag AND delay_days). Underestimating schema expressiveness may require breaking changes to the rule format after coordinators have already configured rules.

Mitigation & Contingency

Mitigation: Define and freeze the rule JSON schema (trigger_type enum, metadata_conditions structure, delay logic) before any implementation begins; validate schema against all known HLF scenarios documented in the feature spec.

Contingency: If schema changes are needed after deployment, implement a schema version field and a migration utility that upgrades stored rules to the new format without coordinator intervention.

medium impact medium prob technical

Deep-link navigation to the activity wizard with pre-filled arguments may fail if the user's session has expired or if the wizard route is not yet mounted in the navigator stack, causing unhandled navigation exceptions.

Mitigation & Contingency

Mitigation: Implement session state check before navigation; if session is expired, redirect to biometric/login screen and store the pending deep-link URI for post-auth redirect using go_router's redirect mechanism.

Contingency: If post-auth redirect proves unreliable, fall back to navigating to the home screen with a visible action banner that re-triggers the wizard with pre-filled arguments.

Quick Links

All Tasks Execution Plan