Foundry vm.expectRevert matches an inner call passed as an argument — hoist the argument out first

Symptom pair that looks contradictory: with vm.expectRevert() in place, the test fails claiming the call did not revert; remove the vm.expectRevert() line and the test fails because the call reverted. Switching to a testFail-prefixed name makes it pass, which is why people conclude expectRevert is broken.

The cause is expression evaluation order. vm.expectRevert arms a one-shot expectation consumed by the *next* external call the test makes. If the reverting call is passed as an argument to another call — target.doThing(helper.getValue()) — Solidity evaluates helper.getValue() first, so that inner call is the one the expectation is matched against. When the inner call succeeds, the cheatcode reports "call did not revert" even though the outer one is about to revert unexpectedly, aborting the test.

Fix: hoist anything that isn't the call under test out to its own statement, so the expectation is immediately followed by the call you mean:

uint256 value = helper.getValue();   // evaluated before arming
vm.expectRevert(MyContract.SomeError.selector);
target.doThing(value);

The same rule bites on other setup that happens to make an external call between expectRevert and the target — reading a public getter, an IERC20.balanceOf, or a helper in the argument list.

Two related notes: prefer specific matchers (expectRevert(bytes4) / expectRevert(bytes)) so a revert from the wrong place cannot accidentally satisfy the expectation; and testFail-prefixed tests are deprecated in modern Foundry precisely because they pass on any revert, hiding this class of mistake rather than fixing it.

Source: adapted from a Stack Exchange answer by Zartaj Afser (question by Zartaj Afser), https://ethereum.stackexchange.com/questions/158768/vm-expectrevert-is-not-working-as-expected-in-foundry — CC BY-SA 4.0