| name | anti-legacy:test-scripts |
| description | Generate stakeholder-facing FUNCTIONAL test scripts across four types — data-parity (legacy vs modern), UAT (Given/When/Then Gherkin), end-to-end business journeys, and API/contract — from the requirements graph + blueprint + test contracts, written under .anti-legacy/deliverables/tests/. Functional, NOT unit. Complements (does not replace) the gated build-binding tests from anti-legacy:functional-tests. Use when: "generate functional test scripts", "write the acceptance tests", "parity/UAT/E2E/API tests", "produce the test scripts deliverable".
|
anti-legacy:test-scripts
Renders functional test scripts — the human-facing acceptance assets a delivery
team and the business sign off on — across the four test types the pipeline cares
about. It SCAFFOLDS the tree deterministically from the structured pipeline data,
then YOU (the agent) ENRICH each scaffold with the concrete assertions each test
contract already specifies. These are functional / behavioural tests, never unit
tests.
This is the early, broad sibling of anti-legacy:functional-tests. That skill
authors the gated, build-binding JUnit/pytest class-existence tests tied to a
contract's target_component and feeds GATE_3. This skill produces the wider,
business-readable functional suite (parity / UAT / E2E / API) as a deliverable. It
complements functional-tests — it does not replace it, and it does not gate.
Mental model
One requirements graph → four test families, each answering a different question:
Type (tests/<dir>/) | Question it answers | Form |
|---|
data-parity/ | Does the modern output equal the legacy output, to the right precision? | JUnit5 parameterized (java) / pytest (python) |
uat/ | Does the capability satisfy the business rule, in business language? | Gherkin .feature (always — stack-agnostic, business-facing) |
e2e/ | Does a full business journey work end-to-end, across requirements? | JUnit5 / pytest / Gherkin journey |
api/ | Does each API return the right status + response shape? | REST-assured+JUnit5 (java) / requests+pytest (python) |
Every file traces back: req_id → legacy_components → rule/scenario id (§2 of the
contract — the thread never breaks). Each generated file opens with that header.
When it runs & prerequisites
Runs "when the graph is ready" — once
.anti-legacy/requirements/requirements_graph.json exists. It also reads (and
degrades gracefully without):
requirements/blueprint.json — to find which requirements expose an
api{method,path} component (drives api/) and the component class names.contracts/{domain}/{req_id}.contract.json — the scenarios[] and parity_rules[]
that fill the assertions. No contracts → scenario-less SKELETONS from the rules,
and the gap is named in the README. (Run anti-legacy:test-strategy to produce
contracts first if you want enriched output.)
It registers its index and never advances the phase (§Universal Don'ts).
Cross-Platform Notes
Pure Python (test_scripts.py), routed through run.py; all paths via os.path.
Runs identically on macOS / Linux / WSL / Windows. No shell-isms.
Parameters
- stack (optional,
--stack): override the target stack. Defaults to
config.target_stack, falling back to the manifest's project.target_stack.
- --no-register: write the files but do not touch the manifest (hermetic / dry run).
Step 1: Verify prerequisites
python3 .anti-legacy/run.py manifest status
Confirm requirements-graph is registered. If it is not, there is nothing to
scaffold — run the pipeline up to anti-legacy:graph-translator first. Optionally
confirm test-strategy is present; without it the scripts are skeletons.
Step 2: Scaffold the four test families
python3 .anti-legacy/run.py test_scripts
This writes the tree under .anti-legacy/deliverables/tests/ and prints the per-type
counts and every written path. The stack mapping is automatic:
- java → JUnit5 for parity/e2e/api (api uses REST-assured); Gherkin for uat.
- python → pytest for parity/e2e/api; Gherkin for uat.
- any other stack → Gherkin
.feature for uat AND e2e; parity and api emit
nothing but write an explicit stack <x>: ... not yet supported note in the
README (mirrors functional-tests' no-silent-skip behaviour — never a silent empty
emit). If your target is java/python, you should not see those notes.
Coverage rules the scaffolder applies:
data-parity/ — one test per active requirement that has parity_rules or any
numeric output field in its contract scenarios. Requirements with neither are listed
as a gap (no parity target).uat/ — one <domain>.feature, one Scenario per contract scenario (tagged
@<req_id> @<TC-id>), or one skeleton scenario per requirement from its first rule.e2e/ — one journey per domain, its requirements ordered by intra-domain
dependencies (topologically; cycles broken deterministically).api/ — one test per active requirement whose blueprint component declares
api{method,path}; emits a happy-path (status 200 + shape) and, when the contract
has an error scenario, an error-path (≥400) test.
Dropped (disposition: drop) and unresolvable requirements are excluded — they are
not in the build set.
Step 3: ENRICH the scaffolds (the real work)
The scaffolder gets the structure and the traceability right; it cannot invent the
business semantics. Open each generated file and replace the marked // ENRICH /
# ENRICH spots with concrete assertions taken from the contract — do not invent
fixtures the contract already specifies. Per type:
- data-parity — each row is
field, legacyExpected, precision, scenarioId drawn
from the contract's expected_output + parity_rules. Wire the modern value: call
the built component with the scenario inputs and capture the field, replacing the
placeholder == legacy line. Keep the precision/scale assertion — COMP-3 precision
loss is silent and catastrophic (§Universal Don'ts).
- uat — turn each
Given/When/Then into the exact precondition / action / outcome
from the scenario's inputs / expected_output / expected_error. The Scenario
name already cites the rule; keep the @<req_id> tag so the thread holds. Skeleton
scenarios (no contract) must be fleshed out or explicitly left flagged.
- e2e — make each ordered step actually drive its requirement using the journey
state from the prior step, and assert the end-to-end outcome. The order encodes the
dependency chain; preserve it.
- api — set the base URI, send a real request body from a
happy_path scenario,
and assert the response shape (not just the status). For the error path, send an
invalid body from an error scenario and assert the status + error code.
Do not delete the traceability header. Do not collapse two requirements into one file.
Step 4: Done-gate (BLOCKING — assert before registering)
The script self-asserts (graph exists; the index README is non-empty) and exits
non-zero otherwise. Confirm the index and that every active requirement is represented
or explicitly listed as a gap:
python3 -c "
import os, sys
base = '.anti-legacy/deliverables/tests'
idx = os.path.join(base, 'README.md')
ok = os.path.exists(idx) and os.path.getsize(idx) > 0
n = sum(len(fs) for _, _, fs in os.walk(base))
sys.stdout.write('OK index present, %d file(s)\n' % n if ok else 'BLOCKED: no index\n')
sys.exit(0 if ok and n > 1 else 1)
"
If this fails, do not register — surface the gap (no requirements graph, or an
empty index) and stop.
Step 5: Register the index (register only — never advance)
The scaffold step (Step 2) already registers the index when the manifest exists. To
re-register after manual enrichment (idempotent — same artifact id, re-checksummed):
python3 .anti-legacy/run.py test_scripts
This registers tests/README.md as artifact id deliverable-test-scripts
(fmt=markdown, produced_by=anti-legacy:test-scripts,
depends_on=["requirements-graph","test-strategy"]) and appends an
anti-legacy:artifact-registered audit row. It never advances the phase. Use
--no-register for a hermetic dry run.
Output
.anti-legacy/deliverables/tests/data-parity/<domain>/… — parity tests..anti-legacy/deliverables/tests/uat/<domain>.feature — Gherkin acceptance..anti-legacy/deliverables/tests/e2e/<domain>… — per-domain journeys..anti-legacy/deliverables/tests/api/<domain>/… — API/contract tests..anti-legacy/deliverables/tests/README.md — the index: what each dir holds, file
count per type, requirements covered, and the GAPS (no-contract / no-parity-target /
no-rules requirements, plus any unsupported-stack notes). Registered as
deliverable-test-scripts.
Failure cases
- No requirements graph → exit 2, clear stderr. Nothing to scaffold; run the
pipeline to graph-translator first.
- Contracts absent / empty → scripts are scaffolded as scenario-less SKELETONS from
the rules, and every such requirement is named under "Gaps" in the README. This is a
surfaced gap, not a silent pass — enrich by running
anti-legacy:test-strategy.
- Unsupported stack (not java/python) → uat + e2e still emit as Gherkin; parity +
api emit nothing and the README carries an explicit "stack not yet supported" note.
Do not treat the empty parity/api dirs as "done".
- Manifest absent → files are written but registration is a no-op (a deliverable can
be rendered before a full workspace exists).
