Selective Build Test

Postcondition Success Signal

• Build/test matrix includes all and only impacted components.
• Tooling correctly identifies "affected" projects based on git graph.
• Required transitive tests are included where dependencies demand it.
• Quality gates remain unchanged; only the scope is reduced.
• Execution is reproducible and reviewable from the same inputs.

Process

1. Source Review: Inspect the impact set produced by incremental-change-impact and determine the appropriate testing tier (UnitTest, SystemTest, ComponentE2E, E2E, ArchitectureTest) based on the current execution stage (Dev, Pre-commit, Pre-push, CI/CD).
2. Discovery & Implementation:
   • Identify the correct monorepo tool (e.g., Nx, Turborepo) for the project stack.
   • Configure the tool (e.g., nx affected, turbo run --filter=[head]) to only target the identified components and tiers.
3. Verification: Execute the build/test and verify that only the intended components and tiers were processed and that they passed.
4. Documentation: Document the selective execution plan, including which tiers were run and why.
5. Review: Platform/DevOps Engineer and Tech Lead review the selective execution results for correctness, coverage, and alignment with the test execution matrix.

Example Test / Validation

• Change a single component and verify only that component’s build/tests run
• Introduce a dependency change and verify dependent components are included
• Confirm quality gates are identical to full runs for impacted components

Common Red Flags / Guardrail Violations

• Skipping pre-commit hooks or checks “to save time”
• Reducing scope by suppressing tests rather than proving non-impact
• Disabling warnings-as-errors or lint rules to speed up builds
• Incremental logic that is not reproducible or explainable

Recommended Review Personas

• Platform/DevOps Engineer – validates correctness of incremental execution
• Tech Lead – validates standards are not weakened and scope is justified
• Domain Expert – validates dependency assumptions

Skill Priority

P3 – Delivery & Flow
(Must never override P0–P2 constraints.)

Conflict Resolution Rules

• Must consume the output of incremental-change-impact
• Cannot weaken quality gates; only reduces scope
• If uncertainty exists, broaden scope rather than suppress checks (with justification)

Conceptual Dependencies

• incremental-change-impact
• quality-gate-enforcement

Classification

Operational

Notes

Optimise feedback loops, not standards. Faster is acceptable only when correct. Refer to the repository's "Test Execution Matrix" for stage-specific tier requirements.