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
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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 devnetOther 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 (instacks-rpc-client
(0%),stacks-network
(1%), andclarinet-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.
The text was updated successfully, but these errors were encountered: