JUnit Publication and Test Trends

Scenario: Tests fail but Jenkins receives only a shell exit code, so regressions and flaky cases remain invisible.

Pipeline example

post { always { junit testResults: 'reports/**/*.xml', allowEmptyResults: false } }

Structured reports create test history

The junit step parses compatible XML and attaches suites, cases, duration, failure, skip, and trend data. Jenkins cannot infer cases from a shell exit code. Configure the runner to write reports even on failure and publish them in post-always. Use a precise glob and normally reject empty results so a broken runner or wrong directory cannot appear successful.

Test failures commonly make a run unstable; malformed XML or missing required files can fail publication. Define what unstable permits: diagnostics may continue, but promotion generally stops. Preserve console context while keeping stable suite and case names, otherwise renamed tests look removed and newly added rather than continuous.

Flakiness is a defect signal

Retry-until-green biases history. Retain the first attempt, identify retries, and measure intermittent failure by test and environment. Quarantine only with owner, reason, and expiry. A permanent quarantine is silent coverage deletion.

For missing reports inspect runner exit, working directory, timestamps, glob, permissions, and parallel path collisions. For one regression compare duration and failure history across commits and matrix cells. Jenkins trends become useful only when report absence, infrastructure abort, and actual assertion failure remain distinct.

Goal: Practice the concrete behavior in jenkins-labeled-parallel-tests. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.