Waffle: `to.be.reverted` does not work

Found the solution to be the following: instead of

expect(await myContract.connect(bob).deposit()).to.be.reverted;

use

await expect(myContract.connect(bob).deposit()).to.be.reverted;

    "@nomiclabs/hardhat-ethers": "^2.0.2",
    "@nomiclabs/hardhat-waffle": "^2.0.1",
    "@nomiclabs/hardhat-web3": "^2.0.0",
    "chai": "^4.3.4",
    "ethereum-waffle": "^3.4.0",
    "ethers": "^5.4.4",
    "hardhat": "^2.6.0",
    "web3": "^1.5.2"

await expect(contract.revert()).to.be.ok; // always passes even though a reverting transaction should not be ok
await expect(contract.revert()).to.be.revertedWith("literally anything"); // always passes no matter what revert message

Please re-open.

Found the solution to be the following: instead of

expect(await myContract.connect(bob).deposit()).to.be.reverted;

use

await expect(myContract.connect(bob).deposit()).to.be.reverted;

This is correct, if you look at the page for Waffle Chai matchers only the BigNumbers matchers use expect(await), all other matchers are shown using await expect().

for some reason doing this works:

const response = await Token.method()

await expect(response.wait()).to.be.reverted

In my case doing this is the only way Token.method() actually will work for any other assertions.

I’m using a forked version of ethereum mainnet with hardhat.

Same for to.be.reverted and to.be.revertedWith(message) I’m afraid.

I am 95% this has something to do with the hardhat evm – as the revert statements do work when testing against just a locally deployed evm using a jsonrpc client

Ugh. Having same issue. Definitely reverts but test failing even with the await expect(response.wait()).to.be.reverted .

Getting rid of the await fixed it. expect(Token.method()).to.be.reverted worked for me as expected.

Found the solution to be the following: instead of

expect(await myContract.connect(bob).deposit()).to.be.reverted;

use

await expect(myContract.connect(bob).deposit()).to.be.reverted;

This is correct, if you look at the page for Waffle Chai matchers only the BigNumbers matchers use expect(await), all other matchers are shown using await expect().

You’re an actual King…

Commented this on another thread https://github.com/OpenZeppelin/openzeppelin-test-helpers/issues/155#issuecomment-886127598

I was having a similar issue but was able to get it to work by:

1. Removing chai-as-promised
2. Installing ethereum-waffle
3. Setting up chai with the following initialization code:

const hre = require("hardhat");
const chai = require("chai");
const { solidity } = require("ethereum-waffle");
chai.use(solidity);
const { expect } = chai;

The issue I ran into was the expect object not having waffle’s matchers. Specifically, expect didn’t know about reverted without having ethereum-waffle installed and chai initialized with solidity from ethereum-waffle.

For me .to.be.revertedWith works, but the message string can be anything and it will still pass. By works I mean, if the method doesn’t revert, the test will fail. So it kind of works, but not fully.

As for .to.be.reverted, no proposed workarounds work…

I’m using hardhat v2.2.1

@eherms This works…so simple. thanks!

Also having this issue when testing against rinkeby with hardhat. I find that the revert message is working as intended only for “revert” within a contract, but NOT for “require”.

Have you found a solution to this problem? I have tested both locally, on hardhat, on rinkeby, and to.be.reverted seems to be invisible for Waffle.

Getting rid of the await fixed it. expect(Token.method()).to.be.reverted worked for me as expected.

Have you tried narrowing the expected results? As shown in my example, it will report to revert successfully even if I pass in a garbage revert message.

I’m getting the same result with revertedWith where it reports a successful revert even if the message doesn’t match with what I’m expecting.

Putting the await on the entire expression worked for me; the revert is successfully expected and fails if the revert message does not match:

await expect(someFn()).to.be.revertedWith('Some revrt message'); // intentional typo on 'revrt'

results in

AssertionError: Expected transaction to be reverted with Some revrt message, but other exception was thrown: Error: VM Exception while processing transaction: reverted with reason string 'Some revert message'

This is happening to me non-deterministically. Sometimes changing the test to call a different contract method and then changing it back fixes it. No idea what’s happening but happy to provide more feedback.

Fixed with PR #96