39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
# 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.
|