Light Client Testing

[ebuchman]

The light client is coming together well, and has some integration tests starting from JSON data generated from Tendermint in Go to test the verify and check_support functions (see tests/lite.rs).

Now that the abstractions are cleaner, we should be adding unit tests to the lite module that use simple mocks for all the traits. These mocks should look basically like what we find in the TLA+ spec, ie. where validator ids are simply integers and a commits just contain the ids of the validators that signed.

As per #110 and #111, we should simplify the public API and have a single primary public function for trying to update the trusted state without making any intermediate requests. The bisection function should use this function. Then we shouldn't need to test verify and check_support independently, as they'd be covered by this new function. Then we'd have two kinds of tests:

1. tests of the new function which cover a "single step". this would be effectively what IBC would use. We'd test for errors like expiration, invalid data, not enough voting power, etc, and we'd test various non-error cases
2. tests for bisection (ie. the current verify_header function). We'd build some mock of a blockchain and instantiate a Requester with it so we can test bisection against different possible existing chains. We'd want to ensure the set of requested headers is correct, as well as all verification results.

In both cases, the tests should map clearly to possible traces from TLC, so that we can generate new tests by running TLC.

We also need a third class of tests:

3. tests for the specific implementations of the traits, primarily of voting_power_in. This would check various actual instantiations of the Tendermint Commit structure and a Validator Set. Would need to ensure nil-votes don't count towards the voting power, and that we error on invalid signatures and on signatures for the wrong block id.

[liamsi]

The context for:

these mocks should look basically like what we find in the TLA+ spec, ie. where validator ids are simply integers and a commits just contain the ids of the validators that signed.

and

In both cases, the tests should map clearly to possible traces from TLC, so that we can generate new tests by running TLC.

seems to be this: https://github.com/interchainio/verification/tree/develop

[ebuchman]

Some of the description here is obsolete by now, but the general fact that we need the testing is not. Also this is prophetic:

tests for the specific implementations of the traits, primarily of voting_power_in. This would check various actual instantiations of the Tendermint Commit structure and a Validator Set. Would need to ensure nil-votes don't count towards the voting power, and that we error on invalid signatures and on signatures for the wrong block id.

Given #282 is exactly this bug, which of course we're not testing ...

[brapse]

The requirements raised here are better addressed by #320.