Cram Sheet208 words
Topic 3.2 — Testing strategy — cram sheet
Topic 3.2 — Testing strategy · cram sheet
Two gate boundaries
| Boundary | Mechanism | Set by |
|---|---|---|
| Merge into a branch | Branch policies | Repo admin |
| Deploy into an environment | Approvals and checks | Resource owner |
A branch policy cannot gate a deployment; a check cannot gate a merge.
Test levels
| Level | Scope |
|---|---|
| Local | Pre-commit |
| Unit | One component, dependencies faked |
| Integration | Components + real dependencies |
| Load | Expected and peak traffic |
- Defect cost: local (minutes) → PR (a build) → production (an incident).
- A test needing a real database is an integration test, whatever the folder says.
- Never blind-retry a flaky test — quarantine or fix.
Implementing tests
- Task:
PublishTestResults@2 - Formats: JUnit · NUnit · VSTest · xUnit · CTest
condition: succeededOrFailed()— without it the publish step is skipped exactly when tests fail. The single most common defect in this objective.
Coverage
- Task:
PublishCodeCoverageResults@2 - Formats: Cobertura · JaCoCo (≠ test result formats)
- Coverage records lines executed, not whether anything was asserted.
- Best gate: coverage of the changed lines.