workflow-brief-to-galaxy-test-plan

Synthesize a Galaxy workflow test plan from the reviewed Workflow Brief and the Galaxy interface and data-flow briefs. Consult retained source evidence when available. 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 into a Galaxy plan. This Mold synthesizes the common brief-driven plan from reviewed acceptance criteria and the testable structure the interface/data-flow briefs and nearest IWC exemplar imply. When retained evidence contains concrete fixtures, snapshots, parameters, or expected results, cite and use them within the selected scope; their presence does not let evidence override the brief.

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 brief or retained evidence carries 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 brief or evidence 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.