Writing Revert Tests for Smart Contracts

Hello! Welcome back to your course on building a cryptocurrency application.

In our last lesson, you successfully wrote tests for the approve and transferFrom functions, which are critical for your token's interoperability. We ended with a small challenge: you wrote a test that failed because your contract correctly rejected an attempt to transfer more tokens than allowed. This is a good thing! It means your contract's security rules are working.

Today, we will learn how to turn those expected failures into passing tests. This practice, often called "unhappy path" testing, is just as important as testing for correct functionality. For a backend developer, this is analogous to writing tests to ensure your API correctly returns a 403 Forbidden or 400 Bad Request status code when it should. A robust smart contract must be predictable not only in success but also in failure.

By the end of this lesson, you will be able to write tests that verify your contracts correctly revert on invalid inputs or when specific conditions are not met, ensuring your application is both functional and secure.

1. The Art of Failing Correctly: Testing Reverts

In Solidity, when a rule is broken, the transaction is "reverted." This stops execution, undoes all state changes made so far in the call, and returns the remaining gas to the caller. These rules are typically enforced using require() statements.

For example, the OpenZeppelin ERC20.sol contract has this line in its _spendAllowance function:
require(currentAllowance >= amount, "ERC20: insufficient allowance");

If the condition isn't met, the transaction reverts and provides that helpful error message. Our job as testers is to create the invalid condition and then assert that the contract reverts with the exact expected message.

To do this, we'll use a special "matcher" function from the hardhat-chai-matchers library, which was installed with your Hardhat project.

2. The revertedWith Matcher

The key to testing reverts is the .to.be.revertedWith() matcher. Let's look at the documentation to understand the pattern.

As the documentation highlights, the syntax is:
await expect(contractCall).to.be.revertedWith("Error message");

The most common mistake is misplacing await. You are not awaiting the result of contractCall (which would throw an error and fail the test). Instead, you are awaiting the resolution of the entire expect assertion.

3. Practical Examples: Testing a Time-Lock Contract

To see this in action, we'll step away from our MyToken contract for a moment and analyze a simple Lock contract. This contract will lock some Ether until a specific time has passed and only allow the owner to withdraw it.

A great way to see this broken down is through a guided video tutorial. We'll watch a few key segments that demonstrate testing for different kinds of reverts.

The contract has three main rules we can test:

1. Constructor: The unlockTime must be in the future.
2. Withdrawal Time: The withdraw function can only be called after unlockTime.
3. Withdrawal Access: Only the owner can call the withdraw function.

Let's see how to test these "unhappy paths."

3.1. Testing an Invalid Constructor Argument

The first test will ensure the contract deployment itself fails if we provide an invalid unlockTime (i.e., a time in the past).

The core of the test looks like this:

// Get the latest block time
const latestTime = await time.latest(); 

// Deploying the contract with a time that is NOT in the future should fail
await expect(
  MyTest.deploy(latestTime, { value: 1 })
).to.be.revertedWith("Your unlock time should be in future");

Here, we simulate providing a bad input to the constructor and assert that the deployment reverts with the precise error message from the contract's require statement.

3.2. Testing Time-Based and Access Control Rules

Next, let's test the withdraw function's rules. We need to check two failure conditions:

1. What happens if someone tries to withdraw too early?
2. What happens if someone other than the owner tries to withdraw?

The tests for these conditions are:

Test 1: Withdrawing too soon.

it("Should revert if called too soon", async function () {
  const { myTest } = await loadFixture(runEveryTime);

  // Calling withdraw() immediately after deployment should fail
  await expect(myTest.withdraw()).to.be.revertedWith(
    "Wait till the time period is completed"
  );
});

This is straightforward. We deploy the contract and immediately try to withdraw, expecting it to fail because the unlockTime has not been reached.

Test 2: Withdrawing from another account.

it("Should revert if called from another account", async function () {
  const { myTest, otherAccount } = await loadFixture(runEveryTime);

  // We use .connect() to send the transaction from another account
  await expect(
    myTest.connect(otherAccount).withdraw()
  ).to.be.revertedWith("You are not an owner");
});

This pattern should be familiar. We use .connect() to have otherAccount call the withdraw function, and we assert that the transaction reverts with the ownership error message.

// test/MyToken.test.ts

describe("Allowances and Delegated Transfers", function () {
  // ... your other tests for approve and transferFrom ...

  it("Should fail if spender tries to transfer more than their allowance", async function () {
    const { myToken, owner, addr1, addr2 } = await loadFixture(deployTokenFixture);
    const amountToApprove = 100;

    // Owner approves addr1 for 100 tokens
    await myToken.approve(await addr1.getAddress(), amountToApprove);

    // addr1 tries to transfer 101 tokens from owner to addr2
    // We expect this transaction to revert with a specific message
    await expect(
      myToken.connect(addr1).transferFrom(
        await owner.getAddress(),
        await addr2.getAddress(),
        amountToApprove + 1
      )
    ).to.be.revertedWith("ERC20: insufficient allowance");
  });
});

Conclusion

Excellent work! You have now mastered one of the most critical skills in smart contract testing: verifying failure conditions. By writing tests that check for reverts, you ensure your contract is robust, secure, and predictable, preventing invalid state transitions and protecting user funds.

Key Takeaways:

• "Unhappy path" testing is crucial for building secure smart contracts. It verifies that your contract fails correctly when rules are broken.
• The primary tool for this in Hardhat is the await expect(...).to.be.revertedWith("Error message") pattern.
• It's essential to place await before expect to await the resolution of the assertion, not the contract call itself.
• You can test for reverts caused by invalid constructor arguments, access control violations (e.g., non-owners), and unmet business logic conditions (e.g., time-locks).

Preview of the Next Lesson:
As your test files grow, you may notice you're writing the same setup code (like deploying your contract) in every it block. This is repetitive and inefficient. In our next lesson, we will learn how to use test fixtures to refactor this setup code, making your tests cleaner, faster, and easier to maintain.