[light-client] Testing Regimen meta-issue

[brapse]

In anticipation of the release of Tendermint-rs Light Client we outline here want we want to be tested. This issue is meant to collect a bunch of sub issues and provide an overview of how correctness will be codified in unit and integration tests. If you are interested in contributing to the test, simply create a break out issue of one of the items and update this issue with a reference ☺️

NOTE: Everything should be tested against the branch in #302 which we expect to be merged shortly (11.6.2020)

Core Verification light-client/src/light_client.rs

• Test that the light client bails out with an error in case target_height < last_trusted_state.height

Verification light-client/src/predicates.rs

~~Broken out into #330~~ The verifier is composed of multiple predicates, each of which should be tested for both the positive and negative case using concrete types. operations should be mocked out.

• validator_sets_match
• next_validators_match
• header_matches_commit
• valid_commit
• is_within_trust_period
• is_monotonic_bft_time
• is_monotonic_height
• has_sufficient_voting_power (related #235)
• has_sufficient_validators_overlap
• has_sufficient_signers_overlap
• valid_next_validator_set

Fork Detection: light-client/src/fork_detector.rs

TODO The Fork detector should be tested in isolation using concrete types to detect the following cases

• Header matches
• Headers differ but verification fails
• Headers differ but verification succeeds

Bisection: light-client/tests/light_client.rs

Requires #290 but could use some help

• All conformance Tests should pass including commit/one_third_vals_don’t_sign.json

Operations: light-client/src/operations/*

The operators provide an abstraction around crypto functions and allow traits to help mock them out during testing. Eventually these should be moved to the main crate but they should be moved there with accompanying tests. Each operator should be tested using concrete types.

• Voting power calculation (#383)
• Commit validation
• Header Hashing

Supervisor verify_to_target integration test: light-client/src/supervisor.rs

#331 The supervisor provides verification using multiple peers. It integrates the io, verification, bisection scheduling, fork detection and evidence reporting. All of which can be mocked out to exercise complex scenarios including

• Perform Bisection into a fork with failed verification (true fork)
  • Should report evidence
• Switching from primary to secondary
• Exhausting peer list

Node Integration

Broken out into #373

• Launch a node with the CLI and sync against the Tendermint proxy App

It’s possible and even likely that this doesn’t cover everything we want to test. Please feel free to discuss in the comments and edit this description as need be.

[josef-widder]

It would be good to have tests when the primary (or secondaries) are not responding. In this case we should timeout and FetchLightBlock should report timeout errors. In case of verification we just terminate with failure then. In the detection we remove the secondary from the peer list. Right now the tests consider only correct/faulty data.

[romac]

Just added support for timeouts to the Io component in the supervisor branch: https://github.com/informalsystems/tendermint-rs/pull/302/commits/8fca5c184edbf78c72f9ad5b412e04fe57babe93

[romac]

Implemented removal of witness which timed out in 56bc022.

[brapse]

It would be good to have tests when the primary

Broken out into a separate issue: https://github.com/informalsystems/tendermint-rs/issues/331

[ebuchman]

We should also run the light-node in CI against a real full node. Originally tracked in #120, made a follow up issue in #373