Skip to main content
The Diff Coverage trend shows how well the code your team merged was tested, week by week. Find it on your project’s Trends page, under Diff Coverage. Where Coverage Trends answers “how much of the codebase is covered today?”, this chart answers “how well tested is the code we’re shipping?” — a project sitting at 60% total coverage that merges 90%-covered changes every week is heading somewhere good, and that shows up here long before it shows up in the total.

​
What’s plotted

  • Diff coverage (line): of the executable lines changed on your default branch during the period, the share that your tests covered.
  • Executable lines changed (bars): how much changed code that percentage is based on. A week with 40 changed lines is a much weaker signal than a week with 4,000.
Pick a range from 1 month to 3 years. Each point covers a week, or a month on the longest ranges, so no single day skews the chart. A point is weighted by size rather than averaged across its days: Qlty adds up the covered lines and the changed executable lines for every day in the period, then divides. A 2,000-line day counts for more than a 20-line day, so one quiet Friday can’t swing the week.

​
How a day is measured

Every night, for each project with coverage, Qlty:
  1. Finds the commit your default branch pointed at when the day started, and the one it pointed at when the day ended.
  2. Diffs the two to get the day’s changed lines.
  3. Checks those lines against the most recent coverage report uploaded for the branch that day.
  4. Stores the covered and changed-executable line counts for the day.
The chart is built from those daily counts, so it only needs coverage uploads on your default branch — there’s nothing extra to configure. It starts on the first day Qlty measured your project, and builds up from there.

​
Gaps in the line

A break in the line means Qlty has no measurement for that period, which happens when:
  • Nothing merged. No commits landed on the default branch.
  • No coverage report. The branch had no coverage uploaded that day.
  • Nothing measurable changed. The day’s changes touched only non-executable lines — comments, docs, config.

​
Merge commits and day boundaries

Qlty uses commit timestamps to decide where one day’s changes end and the next begins. When your default branch has merge commits, its history isn’t linear: a commit can carry a timestamp from days before it actually merged. Those lines are counted on the day they were written rather than the day they landed, so daily boundaries are best effort. In practice this shifts a few lines between neighboring days, which weekly bucketing mostly absorbs. It doesn’t drop changes or double-count them.

​
See Also