diff --git a/scripts/test_doc/test_documentation.md b/scripts/test_doc/test_documentation.md index 8b6d0edccf..beea538a38 100644 --- a/scripts/test_doc/test_documentation.md +++ b/scripts/test_doc/test_documentation.md @@ -23,7 +23,7 @@ | [key_assignment.go](../../tests/integration/key_assignment.go#L33) | TestKeyAssignment | TestKeyAssignment tests key assignments relayed from the provider chain to the consumer chain at different times in the protocol lifecycle.
DetailsEach test scenarios sets up a provider chain and then assigns a key for a validator.
However, the assignment comes at different times in the protocol lifecycle.
The test covers the following scenarios:
* successfully assign the key before the CCV channel initialization is complete, then check that a VSCPacket is indeed queud
* successfully assign the key after the CCV channel initialization is complete
* successfully assign the key during an same epoch where the validator power changes
* get an error when assigning the same key twice in the same block by different validators
* get an error when assigning the same key twice in the same block by the same validator
* successfully assign two different keys in the same block by one validator
* get an error when assigning the same key twice in different blocks by different validators
* get an error when assigning the same key twice in different blocks by the same validator
For each scenario where the key assignment does not produce an error,
the test also checks that VSCPackets are relayed to the consumer chain and that the clients on
the provider and consumer chain can be updated.
| | [misbehaviour.go](../../tests/integration/misbehaviour.go#L19) | TestHandleConsumerMisbehaviour | TestHandleConsumerMisbehaviour tests that handling a valid misbehaviour, with conflicting headers forming an equivocation, results in the jailing of the validators | | [misbehaviour.go](../../tests/integration/misbehaviour.go#L97) | TestGetByzantineValidators | TestGetByzantineValidators checks the GetByzantineValidators function on various instances of misbehaviour.
DetailsThe test sets up a provider and consumer chain.
It creates a header with a subset of the validators on the consumer chain,
then creates a second header (in a variety of different ways),
and checks which validators are considered Byzantine
by calling the GetByzantineValidators function.
The test scenarios are:
* when one of the headers is empty, the function should return an error
* when one of the headers has a corrupted validator set (e.g. by a validator having a different public key), the function should return an error
* when the signatures in one of the headers are corrupted, the function should return an error
* when the attack is an amnesia attack (i.e. the headers have different block IDs), no validator is considered byzantine
* for non-amnesia misbehaviour, all validators that signed both headers are considered byzantine
| -| [misbehaviour.go](../../tests/integration/misbehaviour.go#L394) | TestCheckMisbehaviour | TestCheckMisbehaviour tests that the CheckMisbehaviour function correctly checks for misbehaviour.
DetailsThe test sets up a provider and consumer chain.
It creates a valid client header and then creates a misbehaviour by creating a second header in a variety of different ways.
It then checks that the CheckMisbehaviour function correctly checks for misbehaviour by verifying that
it returns an error when the misbehaviour is invalid and no error when the misbehaviour is valid.
The test scenarios are:
* both headers are identical (returns an error)
* the misbehaviour is not for the consumer chain (returns an error)
* passing an invalid client id (returns an error)
* passing a misbehaviour with different header height (returns an error)
* passing a misbehaviour older than the min equivocation evidence height (returns an error)
* one header of the misbehaviour has insufficient voting power (returns an error)
* passing a valid misbehaviour (no error)
It does not test actually submitting the misbehaviour to the chain or or freezing the client.
| +| [misbehaviour.go](../../tests/integration/misbehaviour.go#L394) | TestCheckMisbehaviour | TestCheckMisbehaviour tests that the CheckMisbehaviour function correctly checks for misbehaviour.
DetailsThe test sets up a provider and consumer chain.
It creates a valid client header and then creates a misbehaviour by creating a second header in a variety of different ways.
It then checks that the CheckMisbehaviour function correctly checks for misbehaviour by verifying that
it returns an error when the misbehaviour is invalid and no error when the misbehaviour is valid.
The test scenarios are:
* both headers are identical (returns an error)
* the misbehaviour is not for the consumer chain (returns an error)
* passing an invalid client id (returns an error)
* passing a misbehaviour with different header height (returns an error)
* passing a misbehaviour older than the min equivocation evidence height (returns an error)
* one header of the misbehaviour has insufficient voting power (returns an error)
* passing a valid misbehaviour (no error)
It does not test actually submitting the misbehaviour to the chain or freezing the client.
| | [normal_operations.go](../../tests/integration/normal_operations.go#L13) | TestHistoricalInfo | Tests the tracking of historical info in the context of new blocks being committed | | [provider_gov_hooks.go](../../tests/integration/provider_gov_hooks.go#L18) | TestAfterPropSubmissionAndVotingPeriodEnded | tests AfterProposalSubmission and AfterProposalVotingPeriodEnded hooks hooks require adding a proposal in the gov module and registering a consumer chain with the provider module | | [provider_gov_hooks.go](../../tests/integration/provider_gov_hooks.go#L60) | TestGetConsumerAdditionLegacyPropFromProp | TestGetConsumerAdditionLegacyPropFromProp manually calls the GetConsumerAdditionLegacyPropFromProp hook on various types of proposals to test the behavior of the hook.
DetailsThe tes case created a provider chain,
then submits a Proposal with various different types of content.
Then, it tries to get the ConsumerAdditionProposal from the proposal using the hook.
Test cases include a proposal with no messages; a proposal with a transfer message; a proposal with an unrelated legacy proposal;
a proposal with an invalid legacy proposal; and a proposal with a ConsumerAdditionProposal.
In the case of a valid ConsumerAdditionProposal, the test verifies that the proposal is found and returned by the hook.
|