Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: invariants #32

Open
varunsrin opened this issue Aug 4, 2022 · 5 comments
Open

testing: invariants #32

varunsrin opened this issue Aug 4, 2022 · 5 comments
Assignees
Labels
test Problems with the test suite
Milestone

Comments

@varunsrin
Copy link
Member

varunsrin commented Aug 4, 2022

Explore foundry's new invariant test model, which maple finance has implemented here.

We might be able to use this to assert invariants while fuzzing, but needs more investigation and there are no docs yet. Probably easiest to wait for a while until docs come out since we have other higher pri items right now.

@varunsrin varunsrin added this to the Görli Migration milestone Aug 6, 2022
@varunsrin
Copy link
Member Author

After some trial and error with invariant testing the problem is that it does not seem to guarantee the invariant as we walk through all other tests in the file. Rather, it fuzzes a series of inputs (sender_address, target_address and calldata) and checks if the invariants are ever violated.

This is fine for asserting that invariants hold within a single function, but there are many logical branches that can only reach when another function has been called with another parameter. Is there any way to such cases?

Next step might be to write out a sample test and prove that the invariant test misses (or catches) such cases, before determining whether to integrate it into our suite. Either way, lower priority for now.

Resources:

@joshieDo
Copy link

joshieDo commented Aug 26, 2022

Saw it linked and wanted to give my take.

but there are many logical branches that can only reach when another function has been called with another parameter. Is there any way to such cases?

Invariant testing does catch these kind of scenarios. But it depends on the complexity and on the probability of such events happening during the testing run. However there are certain branches that it will be very improbable to catch. See this thread for more: foundry-rs/foundry#2851 . We do have some tweaks to catch some: eg if x == CONSTANT, CONSTANT is a PUSHX operation that we add to dictionary, and thus, increase the probability that it will get tested.

To conclude that invariant testing is still a valuable tool to add . But just like any tool, it's incomplete by itself.

@varunsrin varunsrin changed the title Foundry Invariant Testing testing: invariants Aug 27, 2022
@varunsrin
Copy link
Member Author

@joshieDo thanks for the details - is it possible to write invariants for map values?

for instance, an invariant I want to test is idOf[address] != 0 if recoveryClockOf[idOf[address]] != 0

@varunsrin varunsrin removed this from the v2.0.0-beta milestone Aug 27, 2022
@varunsrin varunsrin added the test Problems with the test suite label Sep 24, 2022
@varunsrin varunsrin added the help wanted Extra attention is needed label Feb 24, 2023
@varunsrin varunsrin added this to the v2.0.0-beta2 milestone Feb 26, 2023
@varunsrin
Copy link
Member Author

@horsefacts
Copy link
Collaborator

I'm interested in picking this one up.

@varunsrin varunsrin removed the help wanted Extra attention is needed label Mar 7, 2023
@varunsrin varunsrin modified the milestones: v2.0.0-beta2, v3 Sep 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Problems with the test suite
Projects
None yet
Development

No branches or pull requests

3 participants