Synthesize a Galaxy workflow test plan from a free-form source summary and the Galaxy interface and data-flow briefs. The output is a reviewable handoff conforming to galaxy-workflow-test-plan, not a concrete tests-format file: it records test cases, job inputs, expected outputs, assertion intent, fixture provenance, label assumptions, unresolved mappings, and intentional omissions so implement-galaxy-workflow-test can author the final Galaxy test artifact.
Synthesized, not translated
This is the structural difference from nextflow-test-to-galaxy-test-plan and cwl-test-to-galaxy-test-plan. Those Molds translate existing upstream test evidence — nf-test snapshots, CWL job files and expected outputs — into a Galaxy plan. A free-form source has no upstream test fixtures to convert, so this Mold synthesizes the plan from workflow intent and scenario-level expected outputs: the methods, sample data, parameters, and “expected results” recorded in the free-form summary, plus the testable structure the interface/data-flow briefs and the nearest IWC exemplar imply.
Set the plan’s source.derived_from to intent (not test-evidence) and each synthesized assertion’s evidence to intent; most synthesized assertions are confidence: medium or low. Where the summary does carry a concrete expected value (a known count, a named output token, a published figure), record it as expected_value and raise the confidence.
Labels and fixtures are assumed, not bound
This Mold consumes the template-era briefs, not the concrete workflow draft or the resolved test-data refs — those exist in the harness run-state by the time the plan is authored, but they are reconciled downstream rather than here. So:
- Bind assertions to the labels the interface brief pins, and set
label_status to assumed (or unresolved when even the brief is silent) and the plan’s workflow.label_source to interface-brief. implement-galaxy-workflow-test reconciles these against the real draft labels and the workflow-label cross-check.
- Record fixtures with
storage: unresolved and location: null when the free-form summary names test data only by description; capture what is known (a dataset name, an accession, a Zenodo DOI, a rough size) in fixture.provenance so test-data resolution and the implement Mold can act on it. Use iwc-test-data-conventions for the storage classes and the remote-URL-first convention.
When a binding or fixture cannot be settled from the briefs, add an unresolved[] entry (with blocking: true when the final test cannot be authored without it) rather than inventing a label or a URL.
Choosing assertions from intent
For each expected output the briefs expose, pick the assertion family by output type per planemo-asserts-idioms and a defensible tolerance. When the only exposed output is weakly assertable (a stochastic plot, an opaque binary), consult galaxy-workflow-testability-design: prefer recording assertion intent against a stronger promoted checkpoint, and when you settle for a weak check, record the weaker outputs in omissions[] with a rationale rather than asserting around them. Check each shortcut against iwc-shortcuts-anti-patterns so an existence-only or size-only intent is a deliberate choice.
Keep the plan addressable by stable labels and artifacts (planemo-workflow-test-architecture) so the downstream test, run, and debug Molds can connect assertions back to invocations and outputs.