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

Excluding lines of code from coverage testing #190

Open
aleybovich opened this issue Feb 7, 2018 · 16 comments
Open

Excluding lines of code from coverage testing #190

aleybovich opened this issue Feb 7, 2018 · 16 comments

Comments

@aleybovich
Copy link

Is there a way to exclude some solidity code from coverage testing, like its done in JS with istanbul directives in comments?

@cgewecke
Copy link
Member

cgewecke commented Feb 7, 2018

@aleybovich Currently there is not. Agree this might be useful in some cases though.

@aleybovich
Copy link
Author

@cgewecke Is this something you are planning to do or should I close this issue?

@cgewecke
Copy link
Member

cgewecke commented Feb 8, 2018

@aleybovich I think it should stay open - tagging it as a possible enhancement.

@chapati23
Copy link

maybe just adopt the existing istanbul interface for ignoring code for coverage ?

@cgewecke
Copy link
Member

cgewecke commented Feb 8, 2018

@chapati23 Thanks for that link!

@aleybovich
Copy link
Author

@cgewecke - are you planning to implement this in the future? It would be a very useful feature for many, I'm sure. For example, many contracts have trivial setters with no logic besides assigning a variable (like changing a dependent contract address) and those could be excluded from unit tests.

@fw-aaron
Copy link

fw-aaron commented Jul 5, 2021

Trivial setters may as well be tested. In my situatian, I have code like

function myFunc(MyEnum memory val) {
    if (val == MyEnum.one) {
        ...
    } else if (val == MyEnum.two) {
        ...
    } else {
        revert("Invalid enum value");
    }
}

As far as I can tell, there is no way to reach the revert in the else clause. I don't want to remove the revert though in case some day a new value is added, but is not explicitly supported in this function.

@emretepedev
Copy link

Any update?

@sebastiantf
Copy link

Love to have this.

A use-case is having internal function overrides required by Solidity during multiple inheritances, but not exposed with a public function.

@6str
Copy link

6str commented Jul 1, 2022

I have a helper contract that is used just for tests and I want it to be excluded from the coverage results.

This thread #17 states that ignoring files can be accomplished "using the /* istanbul ignore . . . */ strategy".

I've not been able to exclude the file or specific code using /* istanbul ... */ directives.

In the case of a test helper contract, it would be better if the helper contract was excluded from coverage results rather than included and showing as covered (IMO)

@6str
Copy link

6str commented Jul 20, 2022

maybe just adopt the existing istanbul interface for ignoring code for coverage ?

I couldn't get this to work with hardhat/solidity. It the above meaning that it should be achievable this way now, or a suggestion of a way it could be implemented?

@apecollector
Copy link

Would like this for stuff like supportsInterface and overrides of openzeppelin contracts that are required but difficult to test by themselves.

    // The following functions are overrides required by Solidity.
    function _beforeTokenTransfer(
        address operator,
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory amounts,
        bytes memory data
    ) internal override(ERC1155, ERC1155Supply) {
        super._beforeTokenTransfer(operator, from, to, ids, amounts, data);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC1155, AccessControl)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }

@luiztools
Copy link

I need this too!

@VGabriel45
Copy link

Any updates on this ?

@ricp
Copy link

ricp commented May 23, 2024

+1, would be very useful.

@tmvolpato
Copy link

I need this too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests