pr-integration-test

# PR Integration Test Turn a target PR into durable, behavior-focused integration coverage that proves the fixed path, protects existing behavior, and updates the generated release checklist. ## When to Use This Skill - Convert an open or merged PR into cross-component regression coverage. - Extend `doc/release-check-list.md` and make report scripts check the new rows. - Audit whether a PR's existing tests cover the user-visible behavior rather than only its implementation details. ## Prerequisites - Read `test/e2e/README.md` and reuse the ItE2E framework instead of creating a parallel harness. - Treat the source revision and deployed package as separate decisions. For a PR, test the intended PR head/feature-branch revision through a Dev build by default; a previously installed Dev package is not proof that the PR code ran. - Before running any live integration test, identify the target package from the user's request. If the user did not explicitly choose **Dev** or **Store/production**, use `ask_user` and wait for the answer. In a PR context, make **Dev built from the PR head/feature branch** the recommended/default choice. Never select a package solely from installed-package discovery. - Use Store only when the user explicitly asks to test the production/shipped build. Store results establish a production baseline; they do not validate unshipped changes in the PR. - Pin the chosen package through `$env:ITE2E_PACKAGE = 'Dev'` or `$env:ITE2E_PACKAGE = 'Store'` for every live validation command. - Run `pwsh -File test/e2e/bootstrap.ps1 -Check` before live E2E validation. ## Workflow Follow [workflow.md](./references/workflow.md). Track the phases with a TODO list. `analyze PR -> reconstruct behavior -> audit coverage -> design matrix -> write ItE2E -> wire checklist -> validate -> deliver` ## Test Design Standard For every proposed case, record: | Field | Required answer | |-------|-----------------| | Contract | What user-visible behavior must remain true? | | Trigger | What exact action or input exercises it? | | Boundary | Which real component handoff does this test add beyond unit tests? | | Oracle | What deterministic observable proves success or suppression? | | Negative control | What similar input must not trigger the behavior? | | Existing protection | Which existing tests protect old behavior and must still run? | | Checklist title | Which exact bold release-checklist title contains the Pester test name? | ## Oracle Priority Prefer the earliest deterministic product-owned signal: 1. Protocol/event stream 2. Persisted or queryable application state 3. Structured diagnostic log 4. Rendered terminal or UI state 5. LLM-generated text Use model output only when it is the behavior under test; never use it to prove routing, triggers, suppression, or idempotency. ## Release Checklist Contract - Add one unchecked `[E2E]` checklist item per independently releasable behavior. - Give each item a concise bold title that appears verbatim in the matching Pester full name (`Describe.Context.It`). - Prefer exact-title matching. Add `test/e2e/release-coverage-map.psd1` entries only when an exact test name would be misleading or one case intentionally covers multiple checklist items. - Assign stable IDs and verify `[x]` output through the full and incremental report paths in [workflow.md](./references/workflow.md). ## Completion Gate Do not call the work complete until all of these are true: - Pre-fix evidence identifies the regression, and the fixed path crosses the real integration boundary. - For PR validation against Dev, the tested package is proven to contain the intended PR head/feature-branch revision. - Relevant false positives, replay risks, and existing behavior are covered. - The correct build passes related suites and marks new checklist IDs `[x]`; every skip is explained. ## Gotchas - **Never run a live integration test with an implicit or `Auto` package selector.** Ask first, then pin `ITE2E_PACKAGE`. Installed-package discovery cannot establish user intent or prove that a Dev package contains PR code. - **Do not use Store to validate a PR's unshipped code.** Prefer a Dev package built and deployed from the PR head/feature branch. Use Store only for an explicitly requested production baseline and label the result accordingly. - **Do not test only the implementation detail named in the PR.** Reconstruct the end-to-end user path and assert the observable contract. - **Do not duplicate a unit test at E2E level.** Add the missing process, protocol, persistence, packaging, or UI boundary. - **Do not use a successful lower-layer event as proof of the final feature.** When the contract is downstream, assert both the trigger and its downstream effect. - **Do not turn product failures into skips.** Skip only when an external prerequisite is genuinely unavailable. A connected product that behaves incorrectly must fail. ## References - [Detailed PR-to-integration-test workflow](./references/workflow.md) - [ItE2E framework](../../../test/e2e/README.md) - [Release checklist](../../../doc/release-check-list.md)