You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -165,6 +165,22 @@ The `test` block is the actual test. It contains the following:
165
165
-`when`: The conditions under which the test should be run. This includes the parameters that will be used to run the pipeline.
166
166
-`then`: The assertions that should be made. This includes the expected outcomes of the pipeline.
167
167
168
+
### A Note on Test Names
169
+
170
+
In the example above, we used the name "Should run without failures" which is appropriate for a basic test that just checks if the pipeline runs successfully. However, as we add more specific test cases, we should use more descriptive names that indicate what we're actually testing. For example:
171
+
172
+
- "Should convert input to uppercase" - when testing specific functionality
1. Start with "Should" to make it clear what the expected behavior is
179
+
2. Describe the specific functionality or scenario being tested
180
+
3. Be clear enough that if the test fails, you know what functionality is broken
181
+
182
+
As we add more assertions and specific test cases later, we'll use these more descriptive names to make it clear what each test is verifying.
183
+
168
184
In plain English, the logic of the test reads as follows:
169
185
"**When** these _parameters_ are provided to this _pipeline_, **then** we expect to see these results."
170
186
@@ -325,26 +341,46 @@ SUCCESS: Executed 1 tests in 5.239s
325
341
326
342
A simple check is to ensure our pipeline is running all the processes we expect and not skipping any silently. Remember our pipeline runs 6 processes, one called `sayHello` and one called `convertToUpper` for each of the 3 greetings.
327
343
328
-
Let's add an assertion to our test to check the pipeline runs the expected number of processes.
344
+
Let's add an assertion to our test to check the pipeline runs the expected number of processes. We'll also update our test name to better reflect what we're testing.
329
345
330
346
**Before:**
331
347
332
348
```groovy title="tests/main.nf.test"
333
-
then {
334
-
assert workflow.success
335
-
}
349
+
test("Should run without failures") {
350
+
351
+
when {
352
+
params {
353
+
input_file = "${projectDir}/greetings.csv"
354
+
}
355
+
}
356
+
357
+
then {
358
+
assert workflow.success
359
+
}
360
+
361
+
}
336
362
```
337
363
338
364
**After:**
339
365
340
366
```groovy title="tests/main.nf.test"
341
-
then {
342
-
assert workflow.success
343
-
assert workflow.trace.tasks().size() == 6
344
-
}
367
+
test("Should run successfully with correct number of processes") {
368
+
369
+
when {
370
+
params {
371
+
input_file = "${projectDir}/greetings.csv"
372
+
}
373
+
}
374
+
375
+
then {
376
+
assert workflow.success
377
+
assert workflow.trace.tasks().size() == 6
378
+
}
379
+
380
+
}
345
381
```
346
382
347
-
The `workflow.trace` object includes information about the pipeline which we can check. In this case, we're checking the number of tasks is correct.
383
+
The test name now better reflects what we're actually verifying - not just that the pipeline runs without failing, but that it runs the expected number of processes.
348
384
349
385
Let's run the test again to see if it works.
350
386
@@ -360,40 +396,60 @@ https://www.nf-test.com
360
396
361
397
Test Workflow main.nf
362
398
363
-
Test [1d4aaf12] 'Should run without failures' PASSED (1.567s)
399
+
Test [1d4aaf12] 'Should run successfully with correct number of processes' PASSED (1.567s)
364
400
365
401
366
402
SUCCESS: Executed 1 tests in 1.588s
367
403
```
368
404
369
-
Success! The pipeline runs successfully and the test passes. Now we have began to test the details of the pipeline. as well as the overall status.
405
+
Success! The pipeline runs successfully and the test passes. Now we have began to test the details of the pipeline, as well as the overall status.
370
406
371
407
## 1.4. Test the output
372
408
373
-
Let's add an assertion to our test to check the output file was created.
409
+
Let's add an assertion to our test to check the output file was created. We'll also update the test name again to reflect that we're now checking both process execution and output files.
374
410
375
411
**Before:**
376
412
377
413
```groovy title="tests/main.nf.test"
378
-
then {
379
-
assert workflow.success
380
-
assert workflow.trace.tasks().size() == 6
381
-
}
414
+
test("Should run successfully with correct number of processes") {
Test [1d4aaf12] 'Should run without failures' PASSED (1.591s)
471
+
Test [1d4aaf12] 'Should run successfully with correct processes and output files' PASSED (1.591s)
416
472
417
473
418
474
SUCCESS: Executed 1 tests in 1.612s
@@ -534,15 +590,34 @@ Test Process sayHello
534
590
FAILURE: Executed 1 tests in 4.884s (1 failed)
535
591
```
536
592
537
-
The test fails because the `sayHello` process declares 1 input channel but 0 were specified. Let's fix that by adding an input to the process. Remember from part 1, our `sayHello` process takes a single value input.
593
+
The test fails because the `sayHello` process declares 1 input channel but 0 were specified. Let's fix that by adding an input to the process. Remember from part 1, our `sayHello` process takes a single value input. We should also fix the test name to better reflect what we're testing.
538
594
539
595
**Before:**
540
596
541
597
```groovy title="tests/main.sayhello.nf.test"
542
598
process {
543
599
"""
544
-
// define inputs of the process here. Example:
545
-
// input[0] = file("test-file.txt")
600
+
test("Should run without failures") {
601
+
602
+
when {
603
+
params {
604
+
// define parameters here. Example:
605
+
// outdir = "tests/results"
606
+
}
607
+
process {
608
+
"""
609
+
// define inputs of the process here. Example:
610
+
// input[0] = file("test-file.txt")
611
+
"""
612
+
}
613
+
}
614
+
615
+
then {
616
+
assert process.success
617
+
assert snapshot(process.out).match()
618
+
}
619
+
620
+
}
546
621
"""
547
622
}
548
623
```
@@ -552,7 +627,27 @@ process {
552
627
```groovy title="tests/main.sayhello.nf.test"
553
628
process {
554
629
"""
555
-
input[0] = "hello"
630
+
test("Should run without failures and produce correct output") {
631
+
632
+
when {
633
+
params {
634
+
// define parameters here. Example:
635
+
// outdir = "tests/results"
636
+
}
637
+
process {
638
+
"""
639
+
input[0] = "hello"
640
+
"""
641
+
}
642
+
}
643
+
644
+
then {
645
+
assert process.success
646
+
assert snapshot(process.out).match()
647
+
}
648
+
649
+
}
650
+
556
651
"""
557
652
}
558
653
```
@@ -569,9 +664,9 @@ https://www.nf-test.com
569
664
570
665
Test Process sayHello
571
666
572
-
Test [f91a1bcd] 'Should run without failures' PASSED (1.604s)
667
+
Test [f91a1bcd] 'Should run without failures and produce correct output' PASSED (1.604s)
573
668
Snapshots:
574
-
1 created [Should run without failures]
669
+
1 created [Should run without failures and produce correct output]
575
670
576
671
577
672
Snapshot Summary:
@@ -627,7 +722,7 @@ https://www.nf-test.com
627
722
628
723
Test Process sayHello
629
724
630
-
Test [f91a1bcd] 'Should run without failures' PASSED (1.675s)
725
+
Test [f91a1bcd] 'Should run without failures and produce correct output' PASSED (1.675s)
631
726
632
727
633
728
SUCCESS: Executed 1 tests in 1.685s
@@ -679,25 +774,59 @@ We now need to supply a single input file to the convertToUpper process, which i
679
774
- We could re-use the existing data/greetings.csv file
680
775
- We could create it on the fly within the test
681
776
682
-
For now, let's re-use the existing data/greetings.csv file using the example we used with the pipeline level test.
777
+
For now, let's re-use the existing data/greetings.csv file using the example we used with the pipeline level test. As before, we can name the test to better reflect what we're testing.
0 commit comments