Incorrect test contract names when sharing tests in gas snapshot
Component
Forge
Have you ensured that all of these are up to date?
- [X] Foundry
- [X] Foundryup
What version of Foundry are you on?
forge 0.2.0 (e7ef3c2 2023-01-24T00:14:27.601697Z)
What command(s) is the bug in?
forge snapshot
Operating System
macOS (Apple Silicon)
Describe the bug
Forge produces an incorrect snapshot (duplicated test contract names) when the test contracts inherit from a shared test contract, e.g.:
abstract contract SharedTest {
// ... tests here
}
contract Foo is SharedTest {
}
contract Bar is SharedTest {
}
What gets reported in the snapshot produced by forge snapshot is the following:
Bar:testFuzz_Withdraw(uint256,uint128) (runs: 5000, μ: 347652, ~: 336198)
Bar:testFuzz_Withdraw(uint256,uint128) (runs: 5000, μ: 280057, ~: 280031)
Same test contract name and test function names, but somehow the average and the median gas values are different.
I tried to replicate this outside of our private repo, though I couldn't do it. All I can tell is that this happens when the test contract inherit from a shared abstract contract that contains shared tests.
Does Forge identify the tests by their function names, and then it works its way up from there? This would explain why the contract names are the same, though the gas values are different - Forge is tricked into making a resolution to the one of the two contracts (perhaps the last one found?), and using that as to only contract associated with the test.
hmm, this seems weird.
would appreciate a repro. this would make it easier to debug.
I will try to reproduce this.
@PaulRBerg is the test to reproduce issue public now? The gas difference is because fuzzing is also done with values from state and by scraping contract bytecode (so different values since contracts are different). Thanks!
@grandizzy it was this repo though I can't remember the exact commit where this happened
https://github.com/sablier-labs/v2-core
I am not able to reproduce the issue, cannot find any duped entires as the one reported in snapshot - see attached snapshot.txt @PaulRBerg lmk if OK to close this issue