What are our current feelings on adding small test files (e.g. yml files) that are only used in a single module to the

tests

folder? For instance: https://github.com/nf-core/modules/pull/9660/files

I’m fine with it. Alternatively you could write the file to a temporary disk location directly in the nf-test script with some Groovy

I'm still personally against it, for file pollution reasons

pro Jim's method too

Bleh, it is just harder to do that method

I'd rather

main.nf.test

is polluted than forced pollution of my pipeline 😉

test-datasets = dumpster fire

I'm waiting for you to go on a module-like rampage 😉

We should write a helper function in nft-utils that writes an arbitrary string to a temp file in the nf-test dir, strips the indents and returns the path.

or just take the easy route 🤷

Somewhat yes

(only slightly hyperbolic there 😉 )

Fair

nobody runs the module tests

But I seem to vaguely (mis?)remember someone requesting that they stay for regulatory reasons or something

then make it optional

Why is it arbitrary though?

I wouldn't necessarily say it was any more file pollution than including a

nextflow.config

file in the test directory - some tests have multiple of those. IMO it's fine to include a test file for a module in the tests as long as: • the file format is specific to the module - e.g. a config file • it is plaintext • it is very small • you only need one! But I appreciate that not everyone would agree, hence the suggestion you could embed it in the nf-test:

setup {
    new File("${launchDir}/test.yaml").text = """
        freq: "AF"
        depth: "DP"
        altDepth: "AD"
        maxVaf: "1"
""".stripIndent()
}

//...

process {
    """
    input[N] = file("${launchDir}/test.yaml")
    """
}

I also vote to get the file created from the nf-test script, possibly with an helper method from nft-utils. I think it’s paramount we keep the repository tidy and this means knowing what we have and where. At scale, the cleanest is to only allow predefined file types/extensions at predefined locations – that’s what we have at the moment. That means we’re able to do bulk changes when we need to. For instance, currently we can assume that all yml files are of the

meta.yaml

sort, we know the schema they need to be validated against, write CI + nf-core/tools, etc. What happens when we start adding other yml files ? Same for

.config

files. This is a very generic extension, and it’s very specific to this repo to know/assume they are Nextflow config files. If any tool brings its own config file format named

dummy.config

I’m sure it’ll create problems.