# Mailshot Plugin Test Environments

## Purpose

Define the standard environments used for validation, and what each environment is expected to prove.

## Environment Matrix

1. Local Unit/Static Environment
   - Scope: fast syntax and isolated logic checks.
   - Goal: catch regressions early before integration testing.
   - Notes: no fallback behavior unless specifically instructed in requirements.

2. Local Fixture/Preview Environment
   - Scope: browser-visible plugin behavior without requiring full production infrastructure.
   - Goal: verify rendering, configuration handling, and operator workflows.
   - Notes: should execute the same plugin runtime paths as production code where possible.

3. WordPress Integration Environment
   - Scope: plugin activation and execution inside a WordPress runtime.
   - Goal: validate hooks, shortcode/admin integration, and settings persistence.
   - Notes: use representative plugin settings; avoid hidden defaults.

4. Staging/Pre-Production Environment
   - Scope: production-like infrastructure and data connectivity.
   - Goal: final behavioral confidence before release.
   - Notes: verify operational concerns (configuration, permissions, observability, rollback readiness).

## Minimum Validation Expectations

- All changed files pass language-level syntax checks.
- Any new requirement has at least one corresponding validation step.
- Test evidence should identify which environment produced it.

## Traceability

- Requirement definitions are anchored by `requirements/environment.md`.
- Test notes should reference requirement IDs/sections when they exist.