ATS-MBR-MEM-005 Determine membership standing and refresh list status: Acceptance Test Set
Markdown Planning / Membership / Memberships, Applications and Membership Billing / Membership Holdings and Periods / Capability Test Specification Determine membership standing and refresh list status: Acceptance Test Set Coverage Show evidence (sources, provenance, origins, pinned commits)Test Scenarios 9 scenarios proving CAP-MBR-MEM-005 ; 9 bound to an existing test.
01 Read standing across expiry and return api test
Proves BR-CAP-MBR-MEM-005-01 Preconditions Sam has coverage separated by a lapse and a returning term. Steps Read Sam’s standing on dates during grace, during lapse and after his return. Expected Grace follows expiry, lapse follows the 60-day allowance, and return coverage is active. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:modules/memberships/tests/integration/db/membership-functions.integration.spec.ts #answers Sam grace, lapsed, then active across the lapse and rejoin (scenario 4) 02 Distinguish the full range of membership standing api test
Proves BR-CAP-MBR-MEM-005-02 Preconditions Fixtures include empty, pending, future, current, non-benefit, grace, lapsed and suspended memberships. Steps Inspect each fixture’s derived standing and compare the non-benefit type’s result. Expected The fixtures return their expected standing, including active without benefits for the non-benefit type. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:tests/acceptance/memberships/MBR-ACC-0179.acceptance.ts #MBR-ACC-0179: Every status the engine can answer, from the terms and the type's or program's grace: none, pending, future, active, active without benefits, grace, lapsed and suspended, with the same answer from the SQL twins 03 Read current truth despite a stale cache api test
Proves BR-CAP-MBR-MEM-005-03 Preconditions The clock has crossed expiry while saved status still reflects an earlier date. Steps Read the record before refreshing, then compare cached-status and current-status lists. Expected The record reflects expiry before a sweep; cached filtering can lag behind current filtering. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:modules/memberships/tests/integration/services/status-sweep.integration.spec.ts #answers the right status on each side of the expiry before any sweep runs (the resolver needs none) 04 Refresh the memberships at a normal nightly boundary api test
Proves BR-CAP-MBR-MEM-005-04 Preconditions The previous sweep ran yesterday and one membership reaches an expiry boundary tonight. Steps Run the boundary sweep and inspect the examined count and refreshed status. Expected The boundary member is examined and refreshed to grace while mid-period memberships are omitted. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:modules/memberships/tests/integration/services/status-sweep.integration.spec.ts #examines only the memberships with a term at a boundary 05 Record actual expiry and lapse dates once api test
Proves BR-CAP-MBR-MEM-005-05 Preconditions A dated period crosses expiry and grace-end boundaries, including a delayed sweep. Steps Sweep through expiry and repeat the day, then discover a lapse after its boundary. Expected Expiry retains the day after the term end; late lapse retains the day after grace, without duplicate detections. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:modules/memberships/tests/integration/services/status-sweep.integration.spec.ts #records lapsed_detected effective the day after grace ended, even when found late 08 Inspect joining history and continuity episodes api test
Proves BR-CAP-MBR-MEM-005-09 Preconditions Sam’s returning term follows a gap longer than the continuity allowance. Steps Read the original join date and episode periods after the returning term. Expected The original join date is retained and two continuity episodes are returned. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:modules/memberships/tests/integration/db/membership-functions.integration.spec.ts #answers Sam two continuity episodes (scenario 4) 09 Filter and page membership lists without duplicate unit matches api test
Proves BR-CAP-MBR-MEM-005-10 Preconditions A member belongs to multiple chapters under the same ancestor, with status and pagination fixtures. Steps List through ancestor and chapter filters, compare current and saved status, and exercise paging and malformed filters. Expected Each matching membership appears once per result set; paging follows id order and invalid filters are rejected by name. Data Dated memberships, program and type settings, and the controlled clock or listing fixtures relevant to this case. Bound to Source services-membership:modules/memberships/tests/integration/services/affiliations.integration.spec.ts #lists a member of two chapters once under their zone and region, and under each chapter ← Previous Capability Test Specification ATS-MBR-MEM-004 · Withhold membership through suspension and restore its standing: Acceptance Test Set Next Capability Test Specification → ATS-MBR-MEM-006 · Derive package grants and organizational child memberships: Acceptance Test Set