Add fuzz test for epoch finalization/confirmation #375
Conversation
| @@ -589,3 +592,107 @@ func TestStateTransitionOfValidSubmission(t *testing.T) { | |||
| t.Errorf("Epoch Data missing of in unexpected state") | |||
| } | |||
| } | |||
|
|
|||
| func FuzzConfirmAndDinalizeManyEpochs(f *testing.F) { | |||
| datagen.AddRandomSeedsToFuzzer(f, 20) | |||
There was a problem hiding this comment.
| datagen.AddRandomSeedsToFuzzer(f, 20) | |
| datagen.AddRandomSeedsToFuzzer(f, 10) |
To follow similar tactic with other tests.
There was a problem hiding this comment.
tbh this was deliberate, as I consider this logic quite a bit important and the tests are pretty fast so there is no downside from going to 20 iterations
| kDeep := defaultParams.BtcConfirmationDepth | ||
| wDeep := defaultParams.CheckpointFinalizationTimeout |
There was a problem hiding this comment.
| kDeep := defaultParams.BtcConfirmationDepth | |
| wDeep := defaultParams.CheckpointFinalizationTimeout | |
| kDeep := r.Intn(10) + 1 | |
| wDeep := kDeep + r.Intn(100) + 1 |
There was a problem hiding this comment.
those parameters needs to be the same as the ones used in btccheckpoint.Keeper created by InitTestKeepers(t). And InitTestKeepers uses default parameters.
| if j == 1 { | ||
| bestSumbissionInfos[epoch] = uint64(finalizationDepth) | ||
| } | ||
| finalizationDepth = finalizationDepth - 1 |
There was a problem hiding this comment.
We are executing this statement two times in this if condition, why?
There was a problem hiding this comment.
because each state (Finalize, Confirmed, Submitted) have different variable to track depth, so to register proper depth for given epoch we need to know what will be to final state of the epoch.
| finalizationDepth = finalizationDepth - 1 | ||
| } else if epoch <= uint64(numFinalizedEpochs+numConfirmedEpochs) { | ||
| tk.BTCLightClient.SetDepth(blck1.HeaderBytes.Hash(), int64(confirmationDepth)) | ||
| confirmationDepth = confirmationDepth - 1 |
There was a problem hiding this comment.
What if confirmationDepth (initially wDeep - 1) starts less than numConfirmedEpochs * 2 (i.e. the number of times this subtraction, along with the next one are going to be executed) ?
There was a problem hiding this comment.
not sure I understand, but if confirmationDepth would start too low then most probably test would fail, as epoch which we expected to be confirmed would no be.
In general in this test there are three depth intervals:
form math.MaxUint32 to wDeep - those depth will be finalized
from wDepth - 1 to kDeep - those depths will be confirmed
from kDepp - 1 to 0 - those depths will be submitted
And whole data generation is adjusted so that expected blocks, ends in correct intervals
Adds proper fuzz test for the logic which handles epoch finalization/confirmation.