You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Added corpus with support for storing coverage-increasing call sequences, computing coverage on startup for those sequences, etc.
* Update to only commit coverage in call frames which succeeded (did not revert) in the CoverageTracer.
* Updated serialization format for coverage maps and call message to use hex strings rather than base64.
* Fix for TxContext during TestChain block production
* Changed coverage to be collected per deployment address/code hash
* Added support for init bytecode coverage in CoverageMaps
* Added DeploymentOrder configuration variable which explicitly dictates the order for contracts to be deployed in (for corpus determinism).
* Refactoring of Fuzzer unit test API
* Improved bytecode matching
* Added validation for DeploymentOrder
* Added events throughout Fuzzer/FuzzerWorker, moved TestCaseProvider to be event/hook driven.
* Made EventEmitter's accepted event handlers always return an error type (so errors can be passed around). Refactored all usages of it.
Co-authored-by: David Pokora <[email protected]>
@@ -63,8 +66,14 @@ The structure is described below:
63
66
-`timeout` refers to the number of seconds before the fuzzing campaign should be terminated. If a zero value is provided, the timeout will not be enforced. The timeout begins counting after compilation succeeds and the fuzzing campaign is starting.
64
67
-`testLimit` refers to a threshold of the number of function calls to make before the fuzzing campaign should be terminated. Must be a non-negative number. If a zero value is provided, no call limit will be enforced.
65
68
-`maxTxSequenceLength` defines the maximum number of function calls to generate in a single sequence that tries to violate property tests. For property tests which require many calls to violate, this number should be set sufficiently high.
69
+
-`corpusDirectory` refers to the path where the corpus should be saved. The corpus collects artifacts during a fuzzing campaign that help drive fuzzer features (e.g. coverage-increasing call sequences which the fuzzer collects to be mutates).
70
+
-`coverageEnabled` refers to whether coverage-increasing call sequences should be saved in the corpus for the fuzzer to mutate. This aims to help achieve greater coverage across contracts when testing.
71
+
-`deploymentOrder` refers to the order in which compiled contracts (contracts resulting from compilation, as specified by the `compilation` config) should be deployed to the fuzzer on startup. At least one contract name must be specified here.
72
+
-**Note**: Changing this order may render entries in the corpus invalid. It is recommended to clear your corpus when doing so.
66
73
-`deployerAddress` defines the account address used to deploy contracts on startup, represented as a hex string.
74
+
-**Note**: Changing this address may render entries in the corpus invalid. It is recommended to clear your corpus when doing so.
67
75
-`senderAddresses` defines the account addresses used to send function calls to deployed contracts in the fuzzing campaign.
76
+
-**Note**: Removing previously existing addresses may render entries in the corpus invalid. It is recommended to clear your corpus when doing so.
68
77
-`testing` defines the configuration for built-in test case providers which can be leveraged for fuzzing campaign.
69
78
-`stopOnFailedTest` defines whether the fuzzer should exit after detecting the first failed test, or continue fuzzing to find other results.
70
79
-`assertionTesting` describes configuration for assertion-based testing.
0 commit comments