Regenerate testing doc

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.<details><summary>Details</summary>Each test scenarios sets up a provider chain and then assigns a key for a validator.<br>However, the assignment comes at different times in the protocol lifecycle.<br>The test covers the following scenarios:<br>* successfully assign the key before the CCV channel initialization is complete, then check that a VSCPacket is indeed queud<br>* successfully assign the key after the CCV channel initialization is complete<br>* successfully assign the key during an same epoch where the validator power changes<br>* get an error when assigning the same key twice in the same block by different validators<br>* get an error when assigning the same key twice in the same block by the same validator<br>* successfully assign two different keys in the same block by one validator<br>* get an error when assigning the same key twice in different blocks by different validators<br>* get an error when assigning the same key twice in different blocks by the same validator<br>For each scenario where the key assignment does not produce an error,<br>the test also checks that VSCPackets are relayed to the consumer chain and that the clients on<br>the provider and consumer chain can be updated.</details> |
 | [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.<details><summary>Details</summary>The test sets up a provider and consumer chain.<br>It creates a header with a subset of the validators on the consumer chain,<br>then creates a second header (in a variety of different ways),<br>and checks which validators are considered Byzantine<br>by calling the GetByzantineValidators function.<br>The test scenarios are:<br>* when one of the headers is empty, the function should return an error<br>* 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<br>* when the signatures in one of the headers are corrupted, the function should return an error<br>* when the attack is an amnesia attack (i.e. the headers have different block IDs), no validator is considered byzantine<br>* for non-amnesia misbehaviour, all validators that signed both headers are considered byzantine</details> |
-| [misbehaviour.go](../../tests/integration/misbehaviour.go#L394) | TestCheckMisbehaviour | TestCheckMisbehaviour tests that the CheckMisbehaviour function correctly checks for misbehaviour.<details><summary>Details</summary>The test sets up a provider and consumer chain.<br>It creates a valid client header and then creates a misbehaviour by creating a second header in a variety of different ways.<br>It then checks that the CheckMisbehaviour function correctly checks for misbehaviour by verifying that<br>it returns an error when the misbehaviour is invalid and no error when the misbehaviour is valid.<br>The test scenarios are:<br>* both headers are identical (returns an error)<br>* the misbehaviour is not for the consumer chain (returns an error)<br>* passing an invalid client id (returns an error)<br>* passing a misbehaviour with different header height (returns an error)<br>* passing a misbehaviour older than the min equivocation evidence height (returns an error)<br>* one header of the misbehaviour has insufficient voting power (returns an error)<br>* passing a valid misbehaviour (no error)<br>It does not test actually submitting the misbehaviour to the chain or or freezing the client.</details> |
+| [misbehaviour.go](../../tests/integration/misbehaviour.go#L394) | TestCheckMisbehaviour | TestCheckMisbehaviour tests that the CheckMisbehaviour function correctly checks for misbehaviour.<details><summary>Details</summary>The test sets up a provider and consumer chain.<br>It creates a valid client header and then creates a misbehaviour by creating a second header in a variety of different ways.<br>It then checks that the CheckMisbehaviour function correctly checks for misbehaviour by verifying that<br>it returns an error when the misbehaviour is invalid and no error when the misbehaviour is valid.<br>The test scenarios are:<br>* both headers are identical (returns an error)<br>* the misbehaviour is not for the consumer chain (returns an error)<br>* passing an invalid client id (returns an error)<br>* passing a misbehaviour with different header height (returns an error)<br>* passing a misbehaviour older than the min equivocation evidence height (returns an error)<br>* one header of the misbehaviour has insufficient voting power (returns an error)<br>* passing a valid misbehaviour (no error)<br>It does not test actually submitting the misbehaviour to the chain or freezing the client.</details> |
 | [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.<details><summary>Details</summary>The tes case created a provider chain,<br>then submits a Proposal with various different types of content.<br>Then, it tries to get the ConsumerAdditionProposal from the proposal using the hook.<br>Test cases include a proposal with no messages; a proposal with a transfer message; a proposal with an unrelated legacy proposal;<br>a proposal with an invalid legacy proposal; and a proposal with a ConsumerAdditionProposal.<br>In the case of a valid ConsumerAdditionProposal, the test verifies that the proposal is found and returned by the hook.</details> |