search

foundry-rs / forge-std

Forge Standard Library is a collection of helpful contracts for use with forge and foundry. It leverages forge's cheatcodes to make writing tests easier and faster, while improving the UX of cheatcodes. For more in-depth usage examples checkout the tests.
Apache License 2.0
842 stars 333 forks source link

Restore `fail` with a message #583

Open CodeSandwich opened 3 months ago

CodeSandwich commented 3 months ago

Back in forge-std v1.7 there was function fail in StdAssertions that accepted the error message. As of v1.9.1 it's gone, which breaks existing tests and requires rewriting using much less convenient assertTrue(false, "Reason to fail").

mds1 commented 3 months ago

I believe fail() was removed as part of the move to native cheatcode assertions from the solidity assertions. You should also be able to fail a test with revert("Reason to fail") which should be similarly convenient. cc @klkvr for more info

There also is vm.skip(bool) to conditionally skip tests if that helps

CodeSandwich commented 3 months ago

I believe that you're referring to this change: https://github.com/foundry-rs/forge-std/commit/14325182bf0aae5b2b858f5f0351ffe35c643248#diff-d79529fa796b868bdba7d0be181244b6d3ee5d3ff0aecb1b5db2d47b78dfb05dL15-L17 and specifically this part of StdAssertion.sol:

-    function fail(string memory err) internal virtual {
-        emit log_named_string("Error", err);
-        fail();
-    }
+     function fail() internal virtual {
+        vm.store(address(vm), bytes32("failed"), bytes32(uint256(1)));
+        _failed = true;
+    }

fail() wasn't removed, it was moved from DSTest to StdAssertion and switched to the native cheatcodes. In the process the fail(err) variant was lost and IMO it could be restored to keep this useful tool around and improve backward compatibility. Previously it was logging err and calling DSTest's fail(), now it could log err and call StdAssertion's fail().

mds1 commented 2 months ago

I see, that seems reasonable to me. What do you think @klkvr @mattsse?

klkvr commented 2 months ago

I see, that seems reasonable to me. What do you think @klkvr @mattsse?

I think we can add vm.fail(string) cheatcode for consistency, I'd prefer to not add methods which are manually logging stuff through log_named_string and keep all formatting/outputting logic in cheatcode implementations