Package com.arc_e_tect.gradle.trackerlens.fixture

Class TrackerLensFixtureGenerator

java.lang.Object
com.arc_e_tect.gradle.trackerlens.fixture.TrackerLensFixtureGenerator
public final class TrackerLensFixtureGenerator extends Object
Generates a calibrated pair of gherkin-progress-history.ndjson and api-contract-progress.ndjson fixtures: run today, the forecast each one produces lands a predictable distance in the future, and still does when run again months later, without anyone hand-editing timestamps.

Calibration, not a formula

ProgressProjector has a specific, adaptive shape - a lookback window capped at 90 days, a 7-day floor below which it refuses to forecast, a particular velocity computation - that this class deliberately does not re-derive as a closed-form equation. Instead, generate(FixtureSpec) builds a candidate dataset, runs it through a real ProgressProjector instance, reads the resulting forecast date, and searches (by varying how many items have already reached each tracker's final stage, and how their timestamps are spread across the lookback window) until the computed forecast lands within a day or two of FixtureSpec.forecastTargetDaysOut(). This is what keeps the fixture correct automatically if ProgressProjector's internals ever change - only this search loop's tolerance and iteration bounds are this class's own concern, never the projector's math.

Default coverage

FixtureSpec.defaults() always yields, on both trackers, at least one record with removedAt set. The API-contract tracker always includes at least one record in each of the five categories a lens typically classifies contracts by - Shadow (implemented, never declared), Mirage (declared, never implemented), Stubbed (a consumer-facing stub exists, independent of implementation or verification status), Doppelganger (declared and implemented, never verified), and Compliant (declared, implemented, and verified) - with a dedicated record that is simultaneously Compliant and still has stubbedAt set, proving stub status is irrelevant once real implementation and verification are both present. The BDD-scenario tracker always includes a representative at each of listed, defined, and implemented, plus a record whose definedAt is never set despite implementedAt being set - the stage-skip case a naive furthest-in-list-order reducer gets wrong. Requesting more than the default count scales every category proportionally rather than padding a fixed handful of them.

  • Constructor Details

    • TrackerLensFixtureGenerator

      public TrackerLensFixtureGenerator()
      Creates a new TrackerLensFixtureGenerator.

  • Method Details

    • generate

      public FixtureResult generate(FixtureSpec spec)
      Generates a calibrated fixture for spec.
      Parameters:
      spec - the generation parameters
      Returns:
      the generated records for both trackers, ready to inspect in memory or write to disk
      Throws:
      FixtureCalibrationException - if no candidate dataset tried against the real ProgressProjector landed within tolerance of FixtureSpec.forecastTargetDaysOut() - see that exception's Javadoc for when this is expected, e.g. a target too aggressive for historyStartDaysAgo