Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test function stops after vm.expectedRevert() when testing a library #4991

Closed
2 tasks
apuigsech opened this issue May 20, 2023 · 1 comment
Closed
2 tasks
Labels
T-bug Type: bug

Comments

@apuigsech
Copy link

Component

Forge

Have you ensured that all of these are up to date?

  • Foundry
  • Foundryup

What version of Foundry are you on?

forge 0.2.0 (db96393 2023-05-11T00:10:51.773583000Z)

What command(s) is the bug in?

forge test -vvv

Operating System

macOS (Apple Silicon)

Describe the bug

I have identified an anomalous behavior in the testing process when it comes to testing libraries, and I would like to provide a more detailed explanation using the given code example:

pragma solidity ^0.8.19;

import "forge-std/Test.sol";

library Lib {
    struct Item {
        uint A;
        uint B;
        uint C;
    }

    function _isValid(Item memory item) internal view {
        console.log("_isValid IN");
        require(item.A > 10, "A need to be higher than 10");
        console.log("A ok");
        require(item.B > 100, "B need to be higher than 100");
        console.log("B ok");
        require(item.C > 1000, "A need to be higher than 1000");
        console.log("C ok");
        console.log("_isValid OUT");
    }
}

contract Contract {
    function _isValid(Lib.Item memory item) public view {
        console.log("_isValid IN");
        require(item.A > 10, "A need to be higher than 10");
        console.log("A ok");
        require(item.B > 100, "B need to be higher than 100");
        console.log("B ok");
        require(item.C > 1000, "A need to be higher than 1000");
        console.log("C ok");
        console.log("_isValid OUT");
    }
}

contract testLib is Test {
    using Lib for Lib.Item;

    function testIsValidLib() public {
        Lib.Item memory item = Lib.Item({A: 0, B: 0, C: 0});

        vm.expectRevert("A need to be higher than 10");
        item._isValid();

        // This is NOT executed
        console.log("This is NOT shown");
        item.A = 11;
        vm.expectRevert("B need to be higher than 100");
        item._isValid();
    }

    function testIsValidContract() public {
        Contract c = new Contract();

        Lib.Item memory item = Lib.Item({A: 0, B: 0, C: 0});

        vm.expectRevert("A need to be higher than 10");
        c._isValid(item);

        console.log("This is shown");
        item.A = 11;
        vm.expectRevert("B need to be higher than 100");
        c._isValid(item);
    }
}

The library, named Lib, defines a struct called Item, along with an internal function _isValid that performs specific validations on an Item object. The contract, named Contract, also includes a function _isValid that performs the same validations as the library's _isValid function.

In the testing process, there is a discrepancy between the behavior of the testIsValidContract function and the testIsValidLib function when encountering a revert caused by the _isValid call. Specifically.

The issue is that the testIsValidLib function does not proceed with its execution beyond the point of the revert, despite the presence of the vm.expectRevert() statement in the code, while testIsValidContract is successfully executed until the end.

I think this inconsistency is unexpected considering the usage of vm.expectRevert() in both scenarios.

This is the outcome that illustrates this behaviour:

❯ forge test -vvv
[⠢] Compiling...
[⠘] Compiling 1 files with 0.8.19
[⠊] Solc 0.8.19 finished in 490.66ms
Compiler run successful!

Running 2 tests for test/Bug.t.sol:testLib
[PASS] testIsValidContract() (gas: 217389)
Logs:
  _isValid IN
  This is shown
  _isValid IN
  A ok

[PASS] testIsValidLib() (gas: 6631)
Logs:
  _isValid IN

Test result: ok. 2 passed; 0 failed; finished in 311.58µs
@apuigsech apuigsech added the T-bug Type: bug label May 20, 2023
@gakonst gakonst added this to Foundry May 20, 2023
@github-project-automation github-project-automation bot moved this to Todo in Foundry May 20, 2023
@mds1
Copy link
Collaborator

mds1 commented May 22, 2023

Thanks for the detailed writeup :)

Closing as a duplicate of #3437, this is currently being fixed in #4945

@mds1 mds1 closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2023
@github-project-automation github-project-automation bot moved this from Todo to Done in Foundry May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-bug Type: bug
Projects
Archived in project
Development

No branches or pull requests

2 participants