30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
# 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.
|