Automated tests about girfreco.jl

[alexjaffray]

@felixhorger @cncastillo I think a good starting point for this is targeting the utility functions in the package as a first step, along with MRIGradients.jl. I will proceed with this, @mrikasper and @nbwuzhe would it be alright if I assigned this to all of us and we can make a checklist of functions for which tests are implemented or are WIP?

[cncastillo]

For MRIGradients.jl, of course, the simplest test is sufficient, even if it is 2D phantom data or 1D data even.

For GIRFReco.jl, I think that the steps of the pipeline in purple ("Own Developed Packages" in the paper) should be individually tested, as well as the whole combined pipeline (integration-test). As those are the things you don't want to break/stop working in GIRFReco.jl. It could be the simplest example you can think of.

It is sometimes the case, that another package you depend on breaks your code, which is not really your fault. In that case, you can let the CI pass if the integration test fails, but at least you will be aware that if someone installs GIRFReco.jl it will not work as expected.

The complexity of the tests is not important. The idea is to catch bugs/breaks. Sometimes, a test like:

...
run_my_function()
@test true #Passes if the function above runs without problems
...

It could be sufficient to make sure nothing has broken.

[mrikasper]

Dear Carlos @cncastillo

For MRIGradients.jl, I think it is definitely straightforward to implement unit tests, and we were contemplating this already during the pre-review process. For GIRFReco.jl, the situation is a bit more intricate, because we are establishing a whole pipeline here. This would probably more fall into the realm of integration testing instead of unit testing.

For example, we could split our main example script into its individual steps and transform each of them into an individual test with the respective reference input and outputs from the example. My only concern is the size of the artifacts (the Julia ones, not the MRI ones), because the data is on the order of a gigabyte. We could probably strip it down to a single slice reconstruction or similar. What do you think, would this qualify as a sufficient testing framework?

Thank you for your input,
Lars

[felixhorger]

I think you could use the example code for reconstruction, and feed in simulated data such as started in testThings.jl (which I also recommend to remove from the root level).

[alexjaffray]

Most recent commit creates a test folder, will begin working on each function test

[alexjaffray]

Automated tests are being worked on, we have figured out some reasonable tests and provided a test set which we will continue filling out over the next small while. We will close this once we have completed the tests.

Updated function list:

• calculate_b0_maps
• get_slice_order
• sync_traj_and_data!
• do_k0_correction!
• adjust_header!
• check_acquisition_nodes!
• validate_siemens_mrd!
• validate_acq_data!
• preprocess_cartesian_data
• remove_oversampling!
• merge_raw_interleaves
• apply_girf!
• apply_k0!
• save_map
• load_map
• shift_kspace!

[alexjaffray]

Finished test writing for GIRFReco as of de34bb8 so I am closing