The code coverage is currently at 78.35% [1] and while it is not that low, it is not that high either. We arguably don't want to chase a 100% code coverage because of diminishing returns, but there is a clear benefit to having more of the code base tested out (easier contributing & reviewing), and there might be low-hanging fruits.

As of today, there are 15,674 tracked lines of code, 12,282 of which are covered, leaving 3,392 of them uncovered or only partially covered. This means that in order to attain a coverage of say 85%, we'd have to cover about 30% of remaining lines, or about 1,000 more lines.

I suggest we try to get there.

How

• Testing dataset code by stubbing data Increasing code coverage by mocking datasets #490

The deepinv.datasets module contains about 400 uncovered lines of code. One of the challenges with testing dataset code is that datasets can't generally be downloaded during CI as it takes time and space. As long as this is the case, we won't be able to meaningfully test the consistency between the actual data and our code, but we can still test the surrounding logic by stubbing in fake data

For instance, in Kholer, there is code responsible for computing the correspondence between (linear) indices, and filenames stored on disk. This is code worth testing. In LidcIdriSliceDataset, there is code responsible for making indexation deterministic, and there is also code responsible for processing DICOM files.

In general, it is also possible to test out that transforms passed in at construction are correctly applied when calling __getitem__.

A lot of the code is also responsible for running integrity checks, those are a bit more difficult to test but there should be ways to do it. Maybe by factoring out most of the code in a separate module responsible for integrity checks, then testing it independently and stubbing it on specific calls.

• Improving coverage of the deepinv.utils module Increase test coverage of deepinv.utils #555

There are 445 uncovered lines of code in the deepinv.utils module. Some of the untested code deals with IO, e.g., in deepinv.utils.demo but even IO related functions contain some logic that can be tested out by stubbing the IO related functions. Other functions are purely computational and can easily be tested, e.g., code in deepinv.utils.tensorlist and deepinv.utils.phantoms. Deprecated functions in deepinv.utils.metrics can easily be tested out.

3. Other low-hanging fruits Miscelaneous code coverage improvements #623

There are cases where code redundancy make for a large number of uncovered lines. This is the case for code in deepinv.models.UNet as the forward pass is implemented separately for scales 2, 3, 4 and 5, even though the logic is the same and could be factored in a single algorithm that would depend on the number of scales. In particular, scales 3 and 5 are not tested and amount for almost 50 uncovered lines of code.

Certain modules are left completely untested, e.g., deepinv.optim.phase_retrieval which contains 52 uncovered lines of code. This is also the case of deepinv.optim.bregman which contains 26 uncovered lines of code. It should be relatively straightforward to test them.

[1] https://app.codecov.io/gh/deepinv/deepinv