Problem
The deterministic data-pretest executes static tests[] fixtures. Endpoints that only serve a sliding time window fail once a fixture's hard-coded date ages out — a static date rots daily, and manually bumping it just rots again.
Concrete example
A station-timetable tool of the form GET /plan/:evaNo/:date/:hour with a fixture { evaNo: '8011160', date: '260606', hour: '08' } returns HTTP 404 the day after, because the upstream only serves the current/near-future window. Sibling tools on the same schema that take only a stable id (e.g. realtime-changes by evaNo) stay green — so the schema can never reach full deterministic-green purely because of the time-bound tool.
Constraint
No silent default: implicitly defaulting the date/hour at request time is not acceptable (no-silent-defaults rule). The dynamic value must be explicit in the fixture.
Proposal
Introduce an explicit, documented dynamic test-fixture token resolved at test-execution time, e.g.:
{{TODAY}} → current date in the fixture's declared format (e.g. YYMMDD){{NOW_HOUR}} → current hour (HH)- optional offset form (e.g.
{{TODAY+1}}) for near-future windows
Resolution happens in the pretest/test-builder (DataPretest), is explicit in the fixture, and is documented. Applies to any time-bound endpoint, not just transit.
Acceptance
- A time-bound tool can declare a fixture with a dynamic token that resolves to the current date/hour at grading time.
- The pretest produces a deterministic-green result without manual date maintenance.
- Token resolution is explicit (visible in the fixture) and covered by tests.
Problem
The deterministic data-pretest executes static
tests[]fixtures. Endpoints that only serve a sliding time window fail once a fixture's hard-coded date ages out — a static date rots daily, and manually bumping it just rots again.Concrete example
A station-timetable tool of the form
GET /plan/:evaNo/:date/:hourwith a fixture{ evaNo: '8011160', date: '260606', hour: '08' }returns HTTP 404 the day after, because the upstream only serves the current/near-future window. Sibling tools on the same schema that take only a stable id (e.g. realtime-changes byevaNo) stay green — so the schema can never reach full deterministic-green purely because of the time-bound tool.Constraint
No silent default: implicitly defaulting the date/hour at request time is not acceptable (no-silent-defaults rule). The dynamic value must be explicit in the fixture.
Proposal
Introduce an explicit, documented dynamic test-fixture token resolved at test-execution time, e.g.:
{{TODAY}}→ current date in the fixture's declared format (e.g.YYMMDD){{NOW_HOUR}}→ current hour (HH){{TODAY+1}}) for near-future windowsResolution happens in the pretest/test-builder (DataPretest), is explicit in the fixture, and is documented. Applies to any time-bound endpoint, not just transit.
Acceptance