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
The way the Test contract is currently architected is not in line with the principle of separation of concerns.
The most problematic thing IMHO is the fact that the cheats and assertions live under the same roof. This makes it difficult for Forge Std to be composed with other testing assertion contracts, such as PRBTest.
Of course, I'm a bit biased because of PRBTest, but even if we nevermind my intentions, there are many reasons for why people may wish to write their own testing assertion contracts. If anything, maybe they simply don't like either DSTest or PRBTest. Or perhaps they're working with user-defined value types, which need certain overloads for assertEq. Or perhaps they're using a fork of the EVM on which DSTest doesn't compile or doesn't work well. Bottom line is: Forge Std is not as modular as it could be.
Additionally, separating the cheats from the assertions would also tidy up the contracts a bit, since there would be fewer lines of code in each contract.
Solution
Create a Cheats contract and move all cheats there. Test would then inherit from Cheats.
Doing this would make Forge Std more modular. Users would be able to selectively use just the cheats or just the assertions.
The text was updated successfully, but these errors were encountered:
Description
The way the Test contract is currently architected is not in line with the principle of separation of concerns.
The most problematic thing IMHO is the fact that the cheats and assertions live under the same roof. This makes it difficult for Forge Std to be composed with other testing assertion contracts, such as PRBTest.
Of course, I'm a bit biased because of PRBTest, but even if we nevermind my intentions, there are many reasons for why people may wish to write their own testing assertion contracts. If anything, maybe they simply don't like either DSTest or PRBTest. Or perhaps they're working with user-defined value types, which need certain overloads for
assertEq
. Or perhaps they're using a fork of the EVM on which DSTest doesn't compile or doesn't work well. Bottom line is: Forge Std is not as modular as it could be.Additionally, separating the cheats from the assertions would also tidy up the contracts a bit, since there would be fewer lines of code in each contract.
Solution
Create a
Cheats
contract and move all cheats there.Test
would then inherit fromCheats
.Doing this would make Forge Std more modular. Users would be able to selectively use just the cheats or just the assertions.
The text was updated successfully, but these errors were encountered: