Lesson201 words
Implementing tests in a pipeline
Implement tests in a pipeline
Publishing results is what makes tests visible
Running tests produces exit codes; publishing them produces the trend, the failure history and the flaky-test signal. A pipeline that only fails the job throws away everything except pass/fail.
yaml
- task: PublishTestResults@2
inputs:
testResultsFormat: 'JUnit' # JUnit | NUnit | VSTest | xUnit | CTest
testResultsFiles: '**/TEST-*.xml'
mergeTestResults: true
condition: succeededOrFailed()Two details that matter:
condition: succeededOrFailed()— without it the publish step is skipped exactly when tests failed, which is when you most need the results. This is the most common mistake in this objective.- Multiple formats are supported: JUnit, NUnit, VSTest, xUnit, CTest. The format must match what the test runner emits.
Test agents and parallelism
Distributing tests across agents cuts wall-clock time; slicing must be deterministic so a failure is reproducible. Remember jobs run in parallel by default, so a matrix over test slices needs no extra ordering — but it does consume parallel jobs.
Results as a gate
Published results feed the analytics that branch policies and checks can consult, which is how "no merge if tests regressed" becomes enforceable rather than advisory.
Primary sources