Skip to content

Conversation

@moritz-gross
Copy link
Contributor

@moritz-gross moritz-gross commented Jan 14, 2026

after praising the tests today, I was thinking about how I haven't run any test coverage yet ;)

Somehow, this seems more involved for Rust than I thought it would be.
In IntellJ and PyCharm, there are IDE-integrations that immediately let you do it.
RustRover (what a name) doesn't seem to have that (yet).

I managed to get something running with grcov, which generates a report in target/coverage/html/index.html that looks like this:
image

  • Do you already have workflow for test coverage?
  • If not, what do you think about this option?
  • I'm not sure if this will work on Windows nicely
  • If we want to document this workflow, should we add it to the README? It does not have any technical guidance like this so far.
  • Do we want to create a CONTRIBUTING.md for more technical information instead and add this (and some more basics) to it? I think this would be a good idea if there'll be more new people coming

Edit: I think I figured out how to do it with my IDE, but I think it's still a good idea to have a Rust-only way to do this

@NSoiffer
Copy link
Collaborator

I like the idea of code coverage -- I never spent the time looking for such a tool. I don't think it should go in a readme, but rather when there is some developer documentation (I thought there was something minimal in docs/developers.html, but there isn't). It would be good to have it run as part of a check in, although it seems excessive to run it for every push. Maybe a job that runs once per week but also could be triggered manually? The results could be put on github pages and the (non-existent) documentation can point to it. Is that something you know how to do?

I am actually surprised that the coverage is as high as it is. It's too bad it can't figure out coverage for the YAML rules. I guess that could be a long term project for someone.

If there is a way to exclude main.rs from the coverage tests, you should do that. It is a file that I use for testing/debugging because it is easy to do tests while adding something or looking at a bug. I have an alias for env RUST_LOG=DEBUG cargo run |& less for debugging to make things particularly easy.

@moritz-gross
Copy link
Contributor Author

moritz-gross commented Jan 15, 2026

I added it to the testing-section of helpers.md for now.
should be fine to run it manually I think.
Yes, main.rs should be excluded if the results are automatically evaluated, but for now I just ignored that part.
Coverage of the YAMLs is a good idea, but doesn't sound straightforward.

I think it makes sense to split helpers.md and developers.md. Can I just create it in the docs folder or is there more setup needed for that? The page should be used for https://talkingcatsw.github.io/ I assume?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants