Skip to content

Goldens are measured from a factory start, and twice - #40

Open
hemstreet wants to merge 1 commit into
FoxDevCommunity:mainfrom
hemstreet:sweep-hygiene
Open

hemstreet wants to merge 1 commit into
FoxDevCommunity:mainfrom
hemstreet:sweep-hygiene

Conversation

@hemstreet

Copy link
Copy Markdown

Two guards for the same property: a golden should mean the same thing on every machine, every day.

  1. -A on the VFP command line. Without it, the measuring machine's saved settings (Tools > Options > "Set as Default") leak into every golden: ref_buffering.expected needs SET MULTILOCKS ON to reproduce, ref_backward.expected needs SET DECIMALS TO 12. With -A, every machine measures from the factory state, and a golden that needs a setting says so in its own first line.

  2. Each golden is measured twice. An answer that changes from run to run — a clock, the record of a time — is not a golden, and nothing in a single run says so. With this change, --check on procs.prg (which prints a seconds-since-midnight value on 9.0.0.7423) reports NOT MEASURED - what it printed changes from run to run instead of a diff that looks like a product disagreement; a deterministic golden still reports agrees.

Note: the first sweep after this lands will flag the goldens that depended on saved settings — that is the point, and the settings-dependent issue lists the ones found so far. This PR changes the harness only, never a .expected, so CI is unaffected.

Fixes #34 and #35.

…machine's saved settings, and an answer that changes run to run is not measured
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

vfp-expected.mjs: goldens inherit the measuring machine's saved settings - launch VFP with -A and re-measure

1 participant