#Code coverage lists unused derives as not covered

7 messages · Page 1 of 1 (latest)

austere jolt
#

Hi, I'm trying out the recently stabilized -C instrument-coverage using https://github.com/taiki-e/cargo-llvm-cov .
It works surprisingly well, but I found that there is a really annoying effect when using derive. Every derive counts to the total number of functions, lines and regions. So when I have a #[derive(Clone)] on my pub struct because I want to allow cloning, I also need to use that in a test if I want full coverage. That is really distracting to me as I have a bunch of derives that I don't use explicitly use in my tests and I don't see a reason to test them.

Does anyone know a way to get around that?

GitHub

Cargo subcommand to easily use LLVM source-based code coverage (-C instrument-coverage). - GitHub - taiki-e/cargo-llvm-cov: Cargo subcommand to easily use LLVM source-based code coverage (-C instru...

halcyon arrow
#

In some cases it would make sense that you should test the impls that are derived; for example, in the presence of Arc and interior mutability, a derived clone might not have the semantics you want. This argument is pretty weak when your data types are "plain" though.

austere jolt
#

Yeah that's exactly the thing. There are a bunch of really simle pure data structs in my code that I want to have certain derived traits like Clone, Eq and so on

halcyon arrow
#

I suspect that practically there is no alternative to writing tests that cover those impls

#

but, consider that you don't have to test exactly those impls; you can also write tests that clone a structure incidentally as part of testing more interesting code

#

personally I'd be a tiny bit suspicious of test coverage — in the sense of 'is the program adequately tested', not in the sense of a code coverage tool's output — if some impls were not used

#

because there's likely to be some situation worth testing that involves them