Update nf-test guide with chapter #3474
Open
+1,057
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
03 - testing modules 04 - testing subworkflows
✅ Deploy Preview for nf-core-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nf-core-main-site ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
- Updated titles and subtitles for clarity. - Enhanced descriptions of testing processes and principles. - Improved syntax examples and added comments for better understanding. - Clarified the use of setup blocks and input parameters in tests. - Emphasized the importance of MD5 checksums for BAM file testing.
- Clarified the relationship between module and subworkflow testing concepts. - Expanded on the use of `params` blocks for parameter management in tests. - Added examples for loading parameters from files and combining techniques. - Improved explanations of setup blocks for handling dependencies in subworkflows. - Updated essential assertions and testing principles for better comprehension.
jfy133
reviewed
Aug 26, 2025
|
|
||
| ### Basic test syntax | ||
|
|
||
| The basic syntax for a process test follows this structure: |
There was a problem hiding this comment.
I would start by mentioning the file structure of a module.
Your previous chapter only really focused on pipeline level tests, not modules
|
|
||
| The basic syntax for a process test follows this structure: | ||
|
|
||
| ```groovy |
There was a problem hiding this comment.
Suggested change
| ```groovy | |
| ```groovy title="main.nf.test" |
Or whatever we call it
|
|
||
| ### Essential Assertions | ||
|
|
||
| Tests use assertions to verify the expected output of the process in the `then` block. |
There was a problem hiding this comment.
Suggested change
| Tests use assertions to verify the expected output of the process in the `then` block. | |
| Tests use assertions to verify the expected output of the process specified in the `then` block. |
|
|
||
| Tests use assertions to verify the expected output of the process in the `then` block. | ||
|
|
||
| To report multiple failures in a single test run, group your assertions within an `assertAll` block. |
There was a problem hiding this comment.
Suggested change
| To report multiple failures in a single test run, group your assertions within an `assertAll` block. | |
| You can specify multiple assertions to be evaluated together in a single test by specifying them within an `assertAll` block. |
I don't understand this, why are you tracking failures?
|
|
||
| To report multiple failures in a single test run, group your assertions within an `assertAll` block. | ||
|
|
||
| Channels that lack explicit names can be addressed using square brackets and the corresponding index, for example `process.out[0]` for the first channel. This indexing method provides a straightforward way to interact with channels without the need for predefined names. |
There was a problem hiding this comment.
Suggested change
| Channels that lack explicit names can be addressed using square brackets and the corresponding index, for example `process.out[0]` for the first channel. This indexing method provides a straightforward way to interact with channels without the need for predefined names. | |
| Nextflow process output channels that lack explicit names can be addressed using square brackets and the corresponding index, for example `process.out[0]` for the first channel. This indexing method provides a straightforward way to interact with channels without the need for predefined names. |
But what if you have meta/file tuples? If you describe this later on, I would have a link down to it at the bottom
|
|
||
| ## Testing parameter variations | ||
|
|
||
| Test different parameter combinations that affect subworkflow behavior: |
There was a problem hiding this comment.
Suggested change
| Test different parameter combinations that affect subworkflow behavior: | |
| You should make sure to test different parameter combinations that could affect subworkflow behavior. | |
| You can do this with nextflow config files that sit alongside the `main.nf.test` file. |
|
|
||
| ### Overriding parameters with the `params` block | ||
|
|
||
| In addition to a `nextflow.config` file, `nf-test` provides a `params` block within the `when` block to override Nextflow's input `params` for a specific test. This is useful for testing different parameter combinations without creating multiple config files. |
There was a problem hiding this comment.
Suggested change
| In addition to a `nextflow.config` file, `nf-test` provides a `params` block within the `when` block to override Nextflow's input `params` for a specific test. This is useful for testing different parameter combinations without creating multiple config files. | |
| In addition to a `nextflow.config` file, `nf-test` provides a `params` block within the `when` block to override Nextflow's input `params` for a specific test. | |
| This is useful for testing different parameter combinations without creating multiple config files. |
Again I would pick one method and stick wit hit
Comment on lines
+250
to
+252
| output { | ||
| dir = "output" | ||
| } |
There was a problem hiding this comment.
Maybe give a more realiastic example likthe bismark in the example above
|
|
||
| #### Loading parameters from a file | ||
|
|
||
| You can also load parameters from a JSON or YAML file. This is useful for managing complex parameter sets. |
There was a problem hiding this comment.
What sor tof JSON/YAML file, you mean a nextflow one?
|
|
||
| ## Testing output channels comprehensively | ||
|
|
||
| ### BAM file testing with MD5 checksums |
There was a problem hiding this comment.
Why are you singling out BAMs here? Also this is using a plugin not mentioned her yet.
I think these two sections make more sense for the assertion chaper.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
03 - testing modules
04 - testing subworkflows
@netlify /docs/tutorials/tests_and_test_data/components/03_testing_modules