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
For cases where we care about testing across spectrums of well-defined inputs (NOT fuzzing, which concerns itself with identifying malformed inputs), we should standardize use of a common test parameterization methodology.
Ideally, we can use something like table tests, which will likely eventually be supported more natively in foundry (see here).
The overall idea here is to declare your test suite (for an expected set of test inputs and outcomes) as a modifiable storage array, paired with another single input-outcome set that will be used for individual validations.
struct SPTestSet {
uint256 ipAssetInputA;
uint256 ipAssetInputB;
uint256 expectedIpAssetOutput;
}
SPTestSet[] spTestSets; // To iterate over
SPTestSet spTestSet; // To run individual validations on
We can then create a modifier for parameterization using the following:
modifier parameterizeSPTestSet(SPTestSet[] memory spTestSets) {
for (uint256 i = 0; i < testSuite.length; ++i) {
spTestSet = spTestSets[i];
_;
}
}
Then, we can create a function for creating different test set variations:
function generateSPTestSet() {
delete spTestSets; // This is to ensure we can start fresh for each test.
spTestSets.push(SPTestSet(1, 4, 5));
spTestSets.push(SPTestSet(2, 6, 8));
...
return spTestSets;
}
And finally, here is what an actual test might look like:
function test_SPValidation() parameterizeSPTestSet(generateSPTestSet()) {
assertEq(spTestSet.ipAssetInputA + spTestSet.ipAssetInputB, spTestSet.ipAssetOutput);
// Other assertions
}
Standardizing such a method of parameterization will allow us to more quickly iterate on tests that require large sets of defined inputs and outputs.
The text was updated successfully, but these errors were encountered:
For cases where we care about testing across spectrums of well-defined inputs (NOT fuzzing, which concerns itself with identifying malformed inputs), we should standardize use of a common test parameterization methodology.
Ideally, we can use something like table tests, which will likely eventually be supported more natively in foundry (see here).
Until then, the test parameterization strategy used by PRBMath provides a great baseline.
The overall idea here is to declare your test suite (for an expected set of test inputs and outcomes) as a modifiable storage array, paired with another single input-outcome set that will be used for individual validations.
We can then create a modifier for parameterization using the following:
Then, we can create a function for creating different test set variations:
And finally, here is what an actual test might look like:
Standardizing such a method of parameterization will allow us to more quickly iterate on tests that require large sets of defined inputs and outputs.
The text was updated successfully, but these errors were encountered: