https://nf-co.re logo
Join Slack
Powered by
I have a pipeline with many different possible “ro...
# nf-test
a
I have a pipeline with many different possible “routes” • 3/4 input types • multiple configurable steps/tool selections I have ~20 samplesheets which would let me test the majority of the core routes via stubs but I am wondering what the thoughts are here on using 
nf-test
for this? Under the current model I think I would need to generate ~20 different tests (1 per samplesheet), adding and removing new ones as I go. For these full pipeline level tests is this worth the overhead? My alternative idea is to just generate my own sort of “snapshot” with a txt of expected 
md5sum
for each input and possibly parse the last line of the output (
Succeeded     : 72
) to check that the number of called processes has not changed? Does anyone have any clever tricks for reducing the necessary 
nf-test
boilerplate? Is there any plans to develop some sort of reusable test component?
m
That sounds like Sarek
Have you check our setup? Basically the idea is to use a custom lib to create the tests and resume the same assertions more or less
My opinion: pipeline tests are widely different from functions/modules/subworkflows
One really just needs the params (and eventual config/profile) to start the pipeline
And from there, I think it's much easier to write if you capture the same things
and my hope is to port that logic upstream into nf-test
Shout if you want to discuss about it
a
Ah I think you linked me this before! I think the UTILS function there is what I need to adapt. I don't think it should be too hard to adapt it to take an extra value representing the expected number of processes either
m
Why not just capturing the number of successful tasks
If it changes you know something is weird
You can go even further down
Check the snapshot for default. There is one test where I capture the full output
a
True. I was looking at your CI too and it seems to me you don't run the stub tests? (Maybe you just don't have any for the pipeline level)
m
My long term plan is to run stub only locally and test on ci
There no need to run stub on gha as it's pulling all containers just to get the versions
While you have the containers where you develop and channel logic is useful to check when developing
2 Views
Open in Slack
PreviousNext
Powered by