Fuzz Testing #97
Fuzz Testing #97
Conversation
|
@adlerjohn Yeah was debating that myself as well - makes sense, will do. Btw, I believe the CI is failing because native go fuzzing is only supported since 1.18 |
|
yeah, we'll have to update everything to use go 1.18 if we want to use the new fuzzer. we should do this in other repos as well, but it should be done in a separate PR imo. it should also be investigated to make sure that updating here won't effect repos that import this library, as we don't want to update tendermint or the cosmos-sdk until the core team does |
|
Agree, unless and until we want all downstream dependencies to require Go 1.18, we should hold off on this. Unless as you said, you can use a Go 1.18 module in a Go 1.17 project without issue. |
|
Can we close this one until we continue working on it? |
|
Closing as discussed |
Opening this as a draft PR, because I only added one fuzz test so we can get an idea of what it would look like before writing more. Closes #68.
I also exported
ds.Flattened, since it is a useful data structure to have (for example as input toImportExtendedDataSquare)The two tests that were previously in this package are now implemented as subtests. When not running with
-fuzz, they run with the original inputs provided in thef.Addcall.I removed the second half of the
TestEdsRepairTwicetest - since I assume the purpose is to test if the correct error is thrown when there are too many erasures. The case it tests for after repair is covered in theMaximumErasuressubtest anyways. Or am I missing something?