Enhancement: Complete BDD Scenario Isolation with 2-Layer Approach #14

New Issue

arcodange · 2026-04-11T08:07:01+02:00

arcodange commented

2026-04-11 08:07:01 +02:00

Description

Implement complete scenario isolation for BDD tests using the 2-layer approach documented in ADR 0025.

Current Problem

PostgreSQL schema-per-scenario isolation only handles database tables. In-memory application state (user stores, caches, JWT secret managers) persists across scenarios because they are stored in the shared sharedServer Go instance. This causes test pollution where:

User newuser_ created in one scenario causes 409 Conflict in subsequent scenarios
JWT secrets accumulate across scenarios
Cache entries persist between scenarios

Solution: Enhanced 2-Layer Isolation

See ADR 0025 for complete analysis.

Layer 1: Database Isolation (Partially Implemented)

PostgreSQL schema-per-scenario with SET search_path
Schema naming: test_{sha256(feature:scenario)[:8]}
Implemented via BDD_SCHEMA_ISOLATION=true env var

Layer 2: In-Memory State Isolation (TODO)

Clear user repository between scenarios
Reset JWT secrets (Implemented)
Reset caches (if any)
Recreate service instances per schema

Cache Strategy (for future)

When caches are added (Redis, Memcached, in-process):

Use schema hash as key prefix: {sha256(feature:scenario)[:8]}_cache_key
Ensures each scenario gets isolated cache namespace
Works with external cache services

Acceptance Criteria

All scenarios run with BDD_SCHEMA_ISOLATION=true without failures
User newuser_ registration works consistently (no 409 Conflict from previous scenarios)
No in-memory state pollution between scenarios
Validation passes with ./scripts/validate-test-suite.sh 20

ADR 0025: BDD Scenario Isolation Strategies
ADR 0008: BDD Testing
ADR 0024: BDD Test Organization and Isolation

## Description Implement complete scenario isolation for BDD tests using the 2-layer approach documented in ADR 0025. ## Current Problem PostgreSQL schema-per-scenario isolation only handles database tables. In-memory application state (user stores, caches, JWT secret managers) persists across scenarios because they are stored in the shared sharedServer Go instance. This causes test pollution where: - User newuser_ created in one scenario causes 409 Conflict in subsequent scenarios - JWT secrets accumulate across scenarios - Cache entries persist between scenarios ## Solution: Enhanced 2-Layer Isolation See ADR 0025 for complete analysis. ### Layer 1: Database Isolation (Partially Implemented) - PostgreSQL schema-per-scenario with SET search_path - Schema naming: test_{sha256(feature:scenario)[:8]} - Implemented via BDD_SCHEMA_ISOLATION=true env var ### Layer 2: In-Memory State Isolation (TODO) - Clear user repository between scenarios - Reset JWT secrets (Implemented) - Reset caches (if any) - Recreate service instances per schema ### Cache Strategy (for future) When caches are added (Redis, Memcached, in-process): - Use schema hash as key prefix: {sha256(feature:scenario)[:8]}_cache_key - Ensures each scenario gets isolated cache namespace - Works with external cache services ## Acceptance Criteria - All scenarios run with BDD_SCHEMA_ISOLATION=true without failures - User newuser_ registration works consistently (no 409 Conflict from previous scenarios) - No in-memory state pollution between scenarios - Validation passes with ./scripts/validate-test-suite.sh 20 ## Related - ADR 0025: BDD Scenario Isolation Strategies - ADR 0008: BDD Testing - ADR 0024: BDD Test Organization and Isolation

arcodange referenced this issue from a commit

2026-04-11 17:56:48 +02:00

🧪 test: add JWT secret rotation BDD scenarios and step implementations (#12)

arcodange closed this issue

2026-04-11 17:56:48 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arcodange/dance-lessons-coach#14