[Manishearth]

A guideline like "your tests should test all major functionalities of an API" can't be statically checked for example.

It's not about the crate being non checkable, it's about the check being something that needs a human to look at.

[moosingin3space]

I realize that statically checking for tests is reducible to the halting problem, but would it be possible to have some sort of code-coverage checker that would make sure all externally-facing functions have non-zero coverage? That could be used to construct a checklist for a library developer.

[kilotaras]

Code coverage in itself isn't a very useful metric. Classic example is big test with no asserts will get you pretty good coverage.

There's a rather computationally intensive technique called mutation testing where you introduce bugs into code (e.g. change + to -, flip conditionals, etc.) and check that tests fail.

[burntsushi]

Code coverage has been useful to me in practice, so I think blanket statements like "code coverage isn't useful" is very misleading. For example, code coverage has helped me identify specific branches in my code that are untested, which in turn help guide me to write additional unit tests.

You don't need to completely dismiss other testing techniques. Mutation testing can be useful at the same time that code coverage is useful.

[yazaddaruvala]

Totally agreed. Branch coverage has been far more useful to me than line coverage has.

[Manishearth]

Yes, there are code coverage tools and stuff :)

This could be used, sure.