Code coverage and metrics

Code coverage is a nice-to-have but due to rapid development, we've not yet had time to focus on this.

On the other hand, what gets measured, gets improved.

These are the tasks ahead:

1. Make some CI pipeline that is triggered by pushes into the mimblewimble/grin#master branch, or perhaps time based trigger.
2. Update the coverage badge in the grin README.md
3. Copy out coverage numbers periodically here.

Historical code coverage numbers

release	date	coverage	measurement
mainnet	2019-01-21	69.87% coverage, 15834/22663 lines covered	Measured with cargo clean; cargo tarpaulin --all

Fuzz tests

Fuzz testing has been applied to grin, and some nice and relevant bugs squished before they could to harm. But we need more of this. Any skills and ideas on this are very welcome.

Other code metrics

Complexity metrics?

Clippy warnings

Running

cargo clippy -- -A clippy::precedence -A clippy::match_bool -A clippy::cast_lossless -A clippy::redundant_field_names -A clippy::trivially_copy_pass_by_ref -A clippy:clone_on_copy -A clippy::style

is (soon) almost manageable.

There are still a lot of easy PRs possible for making this better.

Note that style-only code changes are not always welcome. Take care to make any such commits in smaller chunks. This avoids causing too large chunks of work for reviewers, others' working on PRs (*), and to spread the risk of causing some obscure bug that nobody knows where it could've come from at least over a longer period of time. Optimally the code coverage would be high enough that most bugs are caught before merge. We still have some bugs getting past the Travis CI guardpost, so if you can write tests, both positive and negative, come to the dev gitter chat and ask for directions on where tests are most sorely needed.

(*) Basically we avoid changing code style in files while someone else is working on them.