Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve code coverage (Q1-2025) #1664

Open
hugocaillard opened this issue Feb 6, 2025 · 0 comments
Open

Improve code coverage (Q1-2025) #1664

hugocaillard opened this issue Feb 6, 2025 · 0 comments

Comments

@hugocaillard
Copy link
Collaborator

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

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.

@github-project-automation github-project-automation bot moved this to 🆕 New in DevTools Feb 6, 2025
@hugocaillard hugocaillard moved this from 🆕 New to 📋 Backlog in DevTools Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

1 participant