high priority high complexity testing pending testing specialist Tier 10

Acceptance Criteria

PeerMentorAggregationService unit tests cover: all repositories succeed (returns full model), one repository fails (returns partial model with error flag for that section), all repositories fail (returns aggregate error), and concurrent fetch ordering does not affect result correctness
PeerMentorDetailBLoC bloc_test tests cover: LoadPeerMentorDetail emits [Loading, Loaded] on success; LoadPeerMentorDetail emits [Loading, PartialError] when aggregation returns partial failure; LoadPeerMentorDetail emits [Loading, Error] when aggregation throws; RefreshPeerMentorDetail emits [Loading, Loaded] on success when called from Loaded state
Widget tests for PeerMentorDetailScreenWidget cover: Loading state shows CircularProgressIndicator; Loaded state shows all five sub-component widget types; PartialError state shows assembled layout with at least one SectionFallbackWidget; Error state shows retry button; Error state retry button dispatches LoadPeerMentorDetail
Pull-to-refresh widget test: drag gesture on RefreshIndicator dispatches RefreshPeerMentorDetail to BLoC
Certification expiry navigation test: tapping CertificationAlertBanner with HLF org and expired cert calls context.push with '/contacts/peer-mentor/:mentorId/course-enrollment'
All tests are deterministic and pass consistently in CI (no flaky timing dependencies)
Test file is organized into clearly labeled describe/group blocks: Aggregation Service, BLoC, Screen Widget — Loading, Screen Widget — Loaded, Screen Widget — Error States, Interactions
Mock objects are defined once per test file using mocktail or mockito and reused across test cases
Total test execution time for the full suite is under 60 seconds on a standard CI runner
All tests pass with flutter test --coverage and coverage report shows >= 85% line coverage for PeerMentorDetailBLoC and PeerMentorDetailScreenWidget

Technical Requirements

frameworks
Flutter
flutter_test
bloc_test
mocktail or mockito
BLoC (flutter_bloc)
GoRouter
data models
PeerMentorDetailBLoC
PeerMentorDetailState
PeerMentorAggregationService
PeerMentorDetailModel
PeerMentorProfile
CertificationModel
AssignedContact
ActivitySummaryModel
performance requirements
All bloc_test tests must complete within 5 seconds each
Widget pump operations must use pumpAndSettle with a timeout to prevent infinite loops in animation-heavy states
security requirements
Test fixtures must not contain real PII — use clearly fictional mentor names, IDs, and contact information
Mock Supabase responses must not reference real database URLs or API keys

Execution Context

Execution Tier
Tier 10

Tier 10 - 11 tasks

Can start after Tier 9 completes

Implementation Notes

Structure the test file into three sections matching the three layers under test: (1) AggregationService tests — pure unit tests with no Flutter framework, using dart:test group(); (2) BLoC tests — using bloc_test's blocTest() macro with act/expect; (3) Widget tests — using flutter_test's testWidgets() with pumped widget trees. For AggregationService parallel failure tests, use Completer objects to simulate delayed repository responses and verify that Future.wait([...]) error semantics are handled correctly (i.e., a single failure does not cancel other in-flight fetches if using Future.wait(eagerError: false) or a custom gather utility). For widget navigation tests, inject a MockGoRouter via a Provider override and assert the push method was called with the expected arguments — avoid relying on real navigation stack changes in widget tests. Define a shared buildTestWidget(BLoC bloc) helper that wraps PeerMentorDetailScreenWidget with all required Providers (BlocProvider, GoRouter, localization) to reduce boilerplate across test cases.

Testing Requirements

Use the bloc_test package for all BLoC state transition tests — do not use raw StreamController mocking. Use mocktail for repository mocks (preferred over mockito for null-safety ergonomics). For widget tests, inject the BLoC via BlocProvider with a MockBLoC created using bloc_test's MockBloc. Use whenListen to pre-seed BLoC states for widget rendering tests.

For navigation tests, use GoRouter's testing overrides or a custom NavigatorObserver to capture push calls. For the aggregation service parallel fetch tests, use Future.wait with mocked async delays to verify partial failure handling. Run all tests with flutter test --coverage and assert >= 85% line coverage on BLoC and screen widget files.

Component
Peer Mentor Detail BLoC
service medium
Epic Risks (3)
medium impact medium prob technical

The parallel Future.wait aggregation pattern may produce race conditions or incorrect merged state when some repositories resolve significantly faster than others, particularly if the BLoC receives a RefreshDetail event while a prior fetch is still in flight.

Mitigation & Contingency

Mitigation: Implement cancellation token pattern in the aggregation service to abort in-flight fetches on new events. Add BLoC test scenarios for rapid successive refresh events to validate state consistency.

Contingency: If race conditions persist, switch to a sequential-with-timeout fetch strategy for the first release and profile the performance impact before deciding whether parallel fetch optimization is worth the complexity.

medium impact medium prob integration

Integrating PeerMentorDetailScreenWidget into the existing StatefulShellRoute navigation structure may conflict with the Contacts tab's existing route hierarchy, requiring changes to navigation-route-config that could affect other teams' features.

Mitigation & Contingency

Mitigation: Coordinate with the Contact List and Contact Detail feature teams before adding the new route. Review the existing StatefulShellRoute configuration and confirm the peer mentor detail route can be nested under the Contacts branch without path conflicts.

Contingency: If route conflicts arise, temporarily implement the peer mentor detail as a modal overlay (push route) rather than a shell route child, preserving functionality while the navigation architecture conflict is resolved.

low impact high prob dependency

The course enrollment screen that the certification alert banner links to may not yet exist or may be implemented in a separate feature epic, leaving a broken navigation tap for HLF users in the initial release.

Mitigation & Contingency

Mitigation: Check the certification management feature implementation status before finalizing Epic 4 scope. If the enrollment screen is not available, design the tap action to open the HLF course enrollment URL in an external browser as an interim solution.

Contingency: Implement the CTA as a configurable action: if the enrollment route exists in the router, push it; otherwise, launch the configured org-specific enrollment URL via url_launcher, ensuring HLF users can always take action on expired certifications.