Skip to content

Conversation

@omarinuwa
Copy link

This PR adds assertion function aliases that match forge-std/Test.sol naming conventions, resolving naming conflicts and enabling seamless integration with existing Foundry codebases.

Problem:
When integrating crytic/properties with existing Foundry projects, many assertion helpers collided with forge-std/Test.sol, making it difficult to use both libraries together. Specific conflicts:

  • assertWithMsg (crytic) vs assertTrue (forge-std)
  • assertGte (crytic) vs assertGe (forge-std)
  • assertLte (crytic) vs assertLe (forge-std)
  • assertNeq (crytic) vs assertNotEq (forge-std)

Solution:
Added 8 new assertion function aliases in PropertiesHelper.sol that delegate to existing implementations:

  • assertTrue() - alias for assertWithMsg()
  • assertFalse() - new function for asserting false conditions
  • assertNotEq() - alias for assertNeq() (uint256 and int256)
  • assertGe() - alias for assertGte() (uint256 and int256)
  • assertLe() - alias for assertLte() (uint256 and int256)

Benefits:

  • Users can now inherit from both PropertiesAsserts and forge-std Test without naming conflicts
  • Both naming conventions work side-by-side
  • 100% backward compatible - existing code continues to work
  • No breaking changes to existing properties
  • Easier onboarding for Foundry developers

This change makes crytic/properties fully compatible with Foundry's standard testing patterns, lowering the barrier to adoption.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Omar Inuwa seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

This PR adds assertion function aliases that match forge-std/Test.sol
naming conventions, resolving naming conflicts and enabling seamless
integration with existing Foundry codebases.

Problem:
When integrating crytic/properties with existing Foundry projects, many
assertion helpers collided with forge-std/Test.sol, making it difficult
to use both libraries together. Specific conflicts:
- assertWithMsg (crytic) vs assertTrue (forge-std)
- assertGte (crytic) vs assertGe (forge-std)
- assertLte (crytic) vs assertLe (forge-std)
- assertNeq (crytic) vs assertNotEq (forge-std)

Solution:
Added 8 new assertion function aliases in PropertiesHelper.sol that
delegate to existing implementations:
- assertTrue() - alias for assertWithMsg()
- assertFalse() - new function for asserting false conditions
- assertNotEq() - alias for assertNeq() (uint256 and int256)
- assertGe() - alias for assertGte() (uint256 and int256)
- assertLe() - alias for assertLte() (uint256 and int256)

Benefits:
- Users can now inherit from both PropertiesAsserts and forge-std Test
  without naming conflicts
- Both naming conventions work side-by-side
- 100% backward compatible - existing code continues to work
- No breaking changes to existing properties
- Easier onboarding for Foundry developers

Example usage:
```solidity
contract MyTest is MyToken, CryticERC20BasicProperties, Test {
    function test_example() public {
        // Both styles work!
        assertTrue(balance > 0, "Has balance");  // forge-std style
        assertWithMsg(balance > 0, "Has balance"); // crytic style

        assertGe(balance, 100, "At least 100"); // forge-std style
        assertGte(balance, 100, "At least 100"); // crytic style
    }
}
```

This change makes crytic/properties fully compatible with Foundry's
standard testing patterns, lowering the barrier to adoption.
@omarinuwa omarinuwa force-pushed the forge-std-compatibility branch from 4af52ed to 832d59a Compare November 27, 2025 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants