Improve code coverage (2025)

[hugocaillard]

Q1 goals for code coverage on the repository.

Context

Unit and integration tests code coverage is low on Clarinet (43% in January 2025).
Recent PRs showed an improvement (patch coverage in #1622: 88%+, in #1609: 85% – atm). That's because the more automated tests we have, the easier it is to add more. We are settings the boilerplate, fixtures, and best practices for it.

Note 1: some old parts of Clarinet are hard to unit test because they are writen as a few big functions, so unit testing would also mean refactoring parts of the code.
Note 2: part of the coverage is not reported, including all of the integration tests of the sdk (tests written in TS that test the Rust code) and the few wasm_bindgen tests. It's currently challenging to collect the code coverage data.

Do we need more code coverage?

Yes! We do need more unit and integration tests. For 3 main reasons:

• prepare for future refactor and fixes
• prevent regressions
• ship with more confidence and less manual testing Make clarinet release process more reliable #1346

Good test candidates for Q1

Tip

See the coverage by components

Some parts of the code would benefit from being revamped (and improved/fixed). Before doing so, we should test the existing behaviour, getting ready for future work.

• clarinet-deployments (28% covered) – 2k missed lines could lead to a coverage increase of up to 5.8%
• clarinet-files(34% covered) – 800 missed lines could lead to a coverage increase of up to 2.4%
• stacks-rpc (0% covered) – 301 missed lines could lead to a coverage increase of up to 0.8% – this one is easy to test and would need to be tested as we move some of the new remote data fetching code (for the simnet) to this components (see mainnet transaction simulation improvements #1646)
• stacks-network (1.2% ocvered) - 4509 lines could lead to a coverage increase of up to 12.9% – this one is challening to tests do to the heavy integration with docker – could benefit from more tests before future work on the devnet

Other opportunities

• stacks-codec (1.1% covered) accounts for 7% of the missed lines. It's duplicated code from stacks-core that we want to (and should) import from stacks-core instead. Requiring some upstream work on this repo. We should start unit testing some of the code that relies on the stacks-codec first (in stacks-rpc-client (0%), stacks-network (1%), and clarinet-deployements (28%)).

Goals for Q1

Given all of the improvements opportunities listed above, we should target a total of 50% coverage by the end of Q1.
Priorities to be defined.