Module tests about modules

[sven1103]

I think we have to distinguish between a module/process test and documentation. Maybe an own issue for docs?

Regarding module tests: You can think of a module as a set of processes and functions. Each process and function has a particular responsibility. Both consume input data as arguments, execute a task, and can return an output. And it would be nice to test if such a unit executes as expected. That is the fundamental idea of a Unit Test :)

So ideally, a module has a corresponding module test suite, that does exactly that:

1. It sets up the environment and set up the preconditions for the unit (here a Nextflow process or function) (given)
2. It executes the unit (the process or function) (when)
3. It checks assertions about the expected behaviour (then)

How can this look like? Assume we have a module file myModule.nf that contains a process myProcess(). A Test Suite could be a file myModuleTest.nf that actually includes the process from myModule.nf and correctly sets up the environment (linking a container, defines URLs to source data, etc.). Assertions could be realised by just routing the output from the process of interest to an assertionProcess() and check the output there. This process should fail, if at least one assertion was false.

Maybe we can just set up a proof-of-concept test for one of your modules, and see if this works out?

[ewels]

Need to think about where we keep test data and how it is organised.

Suggestion: still use nf-core/test-data but reorganise. Keep everything in one branch, have a set of data under common that can be used by multiple tools. Stuff that is specific to a single tool can then go in subdirectories that mirror nf-core/modules.

[edmundmiller]

So can we consider this one closed now that we've got so many tests we hit the GitHub actions limit?

[drpatelh]

I think we can indeed 😁 🎉