Files
werkator/docs/prs/2026-10-10-PR#143-lighter-processor-time-test.md
claude-code 6f86b96850
werkator build succeeded after 03:07
werkator/deploy build succeeded after 00:08
Lighter processor-time test (v1.38.9) (#143)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-10 12:04:01 +02:00

1.3 KiB

PR#143: Lighter Processor-Time Test

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.

The Problem

The test of Scenario#109.04 in CommandProcessIntegrationTest lets two commands burn processor time, one after the other. Each burns until bash's SECONDS has grown by two, which is one to two seconds, as SECONDS counts whole seconds. So the test takes about 3.3 s of the spec's 3.9 s. PIT runs the spec for every mutant of CommandProcess and ProcessTreeCpuTime it covers.

Non-Goals

  • No change to how the processor time is measured.

The Scenarios

The behaviour does not change, so Scenario#109.04 stays as it is.

The Solution

  • Each command burns half a second, measured by EPOCHREALTIME in microseconds instead of SECONDS. Half a second gives the sampler, which reads every 200 ms, a few readings.
  • EPOCHREALTIME writes the decimal mark of the locale, a comma in a German one, which $((…)) reads as its comma operator; every non-digit is dropped first.
  • The two commands burn at the same time.

The test now takes about 0.5 s instead of 3.3 s.