nextflow-to-test-data

---
type: research
tags:
  - source/nextflow
component: "Nextflow Testing and Test Fixtures"
status: draft
created: 2026-05-01
revised: 2026-09-15
revision: 5
summary: "nf-test patterns mapped to Galaxy planemo asserts and CWL test equivalents — backs the nextflow test-plan Molds and summarize-nextflow §7."
companions:
  - "component-nextflow-testing.yml"
sources:
  - "https://www.nf-test.com/"
  - "https://www.nf-test.com/docs/assertions/"
  - "https://www.nf-test.com/docs/assertions/snapshots/"
  - "https://www.nf-test.com/docs/configuration/"
  - "https://nf-co.re/docs/contributing/nf-test/assertions"
  - "https://nf-co.re/docs/developing/testing/overview"
  - "https://github.com/nf-core/test-datasets"
  - "https://www.nextflow.io/docs/latest/config.html#config-profiles"
  - "https://nf-co.re/docs/contributing/pipelines#test-data"
related_molds:
  - "[[summarize-nextflow]]"
  - "[[nextflow-test-to-galaxy-test-plan]]"
  - "[[nextflow-test-to-cwl-test-plan]]"
  - "[[implement-galaxy-workflow-test]]"
related_notes:
  - "[[nextflow-test-case-selection]]"
  - "[[planemo-asserts-idioms]]"
  - "[[tests-format]]"
  - "[[iwc-test-data-conventions]]"
  - "[[component-nf-core-tools]]"
---

# Nextflow Testing and Test Fixtures

Operational grounding for three Molds:

- [[summarize-nextflow]] §7 — enumerate whole-pipeline `test_candidates[]` and make the default `test_selection` from a real nf-core or DSL2 pipeline.
- [[nextflow-test-to-galaxy-test-plan]] — translate nf-test fixtures + assertions into Galaxy equivalents.
- [[nextflow-test-to-cwl-test-plan]] — the same translation, toward CWL.

The summarize side is mostly *enumeration*: walk `tests/*.nf.test`, extract structured fields per the Mold §7 spec. The translation side is *mapping*: each nf-test assertion pattern has a (
...

# nf-test patterns → Galaxy / CWL test equivalents.
# Companion to component-nextflow-testing.md.
#
# Rows ordered by frequency in real nf-core pipelines (snapshot block first).

mappings:

  # ---- Snapshot block (nf-core canonical idiom) ----

  - id: snapshot.match
    nf_test_pattern: "assert snapshot(...).match()"
    description: "Top-level snapshot assertion comparing serialized form of N captured values to a stored .nf.test.snap file."
    galaxy_equivalent: "Per-output assertion block in <workflow>-tests.yml; no single-line analog. Decompose into per-capture assertions (rows below)."
    cwl_equivalent: "cwltest expected_outputs entries per output; no single-line analog. Decompose."
    target_link: "[[tests-format]]"
    notes: "The whole-snapshot idiom is lossy on translation; explode into N per-capture assertions and accept the surface-area increase."

  - id: snapshot.succeeded_task_count
    nf_test_pattern: "workflow.trace.succeeded().size()"
    description: "Count of successfully completed tasks. nf-core canonical first capture; brittle across pipeline versions but stable per release."
    galaxy_equivalent: "Implicit in workflow execution success. Galaxy workflow tests pass iff the workflow completes; per-step success surfaces via has_text on log outputs."
    cwl_equivalent: "Implicit in cwltest's `should_succeed` / `should_fail` boolean. No per-task count."
    target_link: "[[planemo-asserts-idioms]] §1 (Plain text reports / logs)"
    notes: "Drop on translation; targets verify success implicitly."

  - id: snapshot.versions_yml
    nf_test_pattern: "ch_versions or path('versions.yml')"
    description: "The `versions` topic channel collected per process and dumped to versions.yml at workflow end. nf-core canonical second capture."
    galaxy_equiv
...

---
type: research
tags:
  - target/galaxy
status: draft
created: 2026-05-03
revised: 2026-09-23
revision: 3
related_notes:
  - "[[iwc-workflow-testability-survey]]"
  - "[[iwc-test-data-conventions]]"
  - "[[planemo-asserts-idioms]]"
  - "[[iwc-shortcuts-anti-patterns]]"
  - "[[planemo-workflow-test-architecture]]"
  - "[[implement-galaxy-workflow-test]]"
  - "[[gxformat2-schema]]"
  - "[[gxformat2-workflow-inputs]]"
  - "[[galaxy-datatypes-conf]]"
summary: "Design guidance for Galaxy workflow inputs, outputs, and checkpoints that make IWC-style workflow tests possible."
---

# Design a Galaxy workflow that can be tested

Choose the workflow's public inputs and outputs while designing the analysis, before writing its `-tests.yml`. A workflow test supplies `job:` values by input name and checks `outputs:` by output name. It can only check results the workflow exposes. A good interface gives the test a reproducible input, an addressable result, and at least one assertion that would catch a meaningful wrong result.

This note concerns workflow design. [[iwc-test-data-conventions]] covers the test file's input fixtures, [[planemo-asserts-idioms]] covers assertion syntax, and [[iwc-shortcuts-anti-patterns]] explains when a smoke check is enough. [[iwc-workflow-testability-survey]] holds the broader corpus evidence.

## Name the public interface before writing tests

Give each input and promoted output a stable, descriptive public name. In an exported gxformat2 workflow this is commonly the entry's `id`. The structural [[gxformat2-schema]] also permits `label`. Check the **effective name in the workflow being tested** instead of assuming a step label, generated dataset name, or array position will become the test key. In the pinned [Scanpy workflow](https://github.com/galaxy
...

---
type: research
tags:
  - target/galaxy
status: draft
created: 2026-04-30
revised: 2026-09-23
revision: 4
related_notes:
  - "[[galaxy-workflow-testability-design]]"
  - "[[iwc-shortcuts-anti-patterns]]"
  - "[[planemo-asserts-idioms]]"
  - "[[implement-galaxy-workflow-test]]"
  - "[[tests-format]]"
  - "[[iwc-tabular-operations-survey]]"
summary: "IWC and Planemo workflow-test fixture shapes, file provenance, collection identifiers, input hashes, and built-in index values."
---

# IWC test data conventions

An IWC workflow test pairs each workflow with a sibling `<workflow>-tests.yml`. Each YAML test case supplies `job:` inputs under the workflow's input labels and `outputs:` assertions under its output labels. The optional `test-data/` directory holds local fixtures. These are the [IWC contribution layout](https://github.com/galaxyproject/iwc/blob/main/workflows/README.md) and [Planemo test-format](https://planemo.readthedocs.io/en/latest/test_format.html) contracts. For decisions about the workflow interface before writing fixtures, see [[galaxy-workflow-testability-design]]. For the exact supported YAML vocabulary and static validation, see [[tests-format]].

Examples below come from the cited IWC files or Planemo documentation. Corpus observations describe the workflows sampled for this note, not a rule that every IWC workflow follows.

## Fixture locations and provenance

A `class: File` input can use `path:` for a local fixture or `location:` for a URI. Planemo resolves a relative `path:` from the workflow and test directory. IWC's contribution guide recommends small inputs and suggests publishing a toy dataset to Zenodo for a permanent URL. The repository also permits an optional local `test-data/` directory. It gives no universal size cutoff or mandatory hos
...