This PR adds another PoC, in the same rationale of #375, but for more common actions such as DAI and MKR streams, payments, and yanks. The ultimate goal is to reduce what developer needs to touch in DssSpell.t.sol, and move the common actions (such as payments) to a separate and more auditable testing file, while avoiding disabling and enabling tests that are crucial for the correct check on these actions.
The workflow checks (same as previous tests):
correct length of arrays (e.g. expected amounts of Payees)
correct sum of payments
adds the dates all together (and avoids repeating them for different scopes)
The advantages of this process rationale:
adds no smart-contract security overhead, other than a correct file import at testing
forces (by process) beneficiaries to be declared by name (and be added to addresses_deployers.sol)
a [SKIP] test is easier to detect than a non-existing test
less line modifications in sparsed lines of DssSpell.t.sol
Given that previous spell has no MKR payments or yanks, the test output looks like this:
As you replied in #375, the rule of thumb is to make tests as simple as possible, i agree, there's little advantage in that one (as it touches the changelog, and perhaps needs other process), but perhaps this approach on very common tasks could be a bit more beneficial for the testing process.
This PR adds another PoC, in the same rationale of #375, but for more common actions such as DAI and MKR streams, payments, and yanks. The ultimate goal is to reduce what developer needs to touch in DssSpell.t.sol, and move the common actions (such as payments) to a separate and more auditable testing file, while avoiding disabling and enabling tests that are crucial for the correct check on these actions.
The workflow checks (same as previous tests):
The advantages of this process rationale:
addresses_deployers.sol)[SKIP]test is easier to detect than a non-existing testDssSpell.t.solGiven that previous spell has no MKR payments or yanks, the test output looks like this:
As you replied in #375, the rule of thumb is to make tests as simple as possible, i agree, there's little advantage in that one (as it touches the changelog, and perhaps needs other process), but perhaps this approach on very common tasks could be a bit more beneficial for the testing process.