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

Coverage reports do not cover all contracts #1087

Open
Quaid-Doug opened this issue May 21, 2021 · 11 comments
Open

Coverage reports do not cover all contracts #1087

Quaid-Doug opened this issue May 21, 2021 · 11 comments

Comments

@Quaid-Doug
Copy link

Environment information

  • brownie Version: 1.14.6
  • solc Version: 8.0.0
  • Python Version: 3.8.5
  • OS: linux

What was wrong?

Please include information like:

I have 3 contracts that work in interaction with each others.

My testing script is on one file.

When I run brownie test --coverage I get a coverage report for only one of the contracts. I'd like to get it for all of the contracts.

@bainjamain
Copy link

I found this issue to be quite random. Sometimes the coverages covers all my contracts, but more often than not, it covers only a small subset of the contracts tested, sometimes none.

@igponce
Copy link

igponce commented May 25, 2021

Same issue here with:

  • Brownie v1.14.6

  • Python version 3.6.9

  • Solc

    • 0.7.6
    • 0.8.4
  • / EVM Version: Istambul

I've got coverage for the fist contract I deploy.
I tried changing the contract names to see if alphabetical of contract names was a factor, but no.

@evoh-nft
Copy link

evoh-nft commented Jun 6, 2021

Same problem here. I've noticed that when using solc 0.8.3 I get a normal coverage report, but with 0.8.4 it comes back empty.

@Psirex
Copy link

Psirex commented Jul 13, 2021

I found, that it happens with contracts that use the immutable modifier. Maybe because of this:

"The contract creation code generated by the compiler will modify the contract’s runtime code before it is returned by replacing all references to immutables by the values assigned to them. This is important if you are comparing the runtime code generated by the compiler with the one actually stored in the blockchain."

as mentioned in the docs here. But I'm not sure that it's the only reason which causes such behavior.

danhper added a commit to danhper/brownie that referenced this issue Jul 27, 2021
…sing statements or branches

The previous behavior expects all functions to have a report for both
statements and branches. If not, it removes the whole contract from the
coverage report.
While the assumption seems reasonable, some functions seem to only have
either one of statements or branches, ending up in removing contracts
that would otherwise contain useful coverage information.

This is related to eth-brownie#1087 and should at least be a partial fix to it
danhper added a commit to danhper/brownie that referenced this issue Aug 2, 2021
…sing statements or branches

The previous behavior expects all functions to have a report for both
statements and branches. If not, it removes the whole contract from the
coverage report.
While the assumption seems reasonable, some functions seem to only have
either one of statements or branches, ending up in removing contracts
that would otherwise contain useful coverage information.

This is related to eth-brownie#1087 and should at least be a partial fix to it
danhper added a commit to danhper/brownie that referenced this issue Aug 16, 2021
…sing statements or branches

The previous behavior expects all functions to have a report for both
statements and branches. If not, it removes the whole contract from the
coverage report.
While the assumption seems reasonable, some functions seem to only have
either one of statements or branches, ending up in removing contracts
that would otherwise contain useful coverage information.

This is related to eth-brownie#1087 and should at least be a partial fix to it
danhper added a commit to danhper/brownie that referenced this issue Aug 16, 2021
…sing statements or branches

The previous behavior expects all functions to have a report for both
statements and branches. If not, it removes the whole contract from the
coverage report.
While the assumption seems reasonable, some functions seem to only have
either one of statements or branches, ending up in removing contracts
that would otherwise contain useful coverage information.

This is related to eth-brownie#1087 and should at least be a partial fix to it
danhper added a commit to danhper/brownie that referenced this issue Aug 16, 2021
…sing statements or branches

The previous behavior expects all functions to have a report for both
statements and branches. If not, it removes the whole contract from the
coverage report.
While the assumption seems reasonable, some functions seem to only have
either one of statements or branches, ending up in removing contracts
that would otherwise contain useful coverage information.

This is related to eth-brownie#1087 and should at least be a partial fix to it
danhper added a commit to danhper/brownie that referenced this issue Aug 16, 2021
…sing statements or branches

The previous behavior expects all functions to have a report for both
statements and branches. If not, it removes the whole contract from the
coverage report.
While the assumption seems reasonable, some functions seem to only have
either one of statements or branches, ending up in removing contracts
that would otherwise contain useful coverage information.

This is related to eth-brownie#1087 and should at least be a partial fix to it
@vsmelov
Copy link
Contributor

vsmelov commented Oct 3, 2022

This bug is still active?
I cannot use immutable in my contracts if I want to check test coverage?

@iurii2002
Copy link

Yes, the bug is still active

@FlavorlessQuark
Copy link

I'm having the same issue. I'm using two contracts, and while they both show up in the coverage, it doesn't show all the functions in the contracts.

@Bulalu
Copy link

Bulalu commented Nov 22, 2022

still having the same issue 😢

@jacekv
Copy link

jacekv commented Dec 23, 2022

I ran into the same issue using Brownie v1.18.1.

What @Psirex wrote seems to be the only problem. I have some contracts where only one state variable is set to immutable, which leads to an empty coverage report.

As soon I remove immutable from the state variable, it works.

@jacekv
Copy link

jacekv commented Jan 4, 2023

Actually I was wrong. I had been playing with it a bit more and realized that something seems to be broken.

I tried it with an example project: brownie bake token
The coverage report says 100% but does not identify all functions. The approve is not part of the report for some reason.

@jacekv
Copy link

jacekv commented Jan 5, 2023

I spend some time looking into why the immutable keyword is causing problems, but I was not able to find a solution to the problem, since it would take me more time and resources to understand how browie works under the hood.

I was able to see that there seems to be an issue in the brownie//network/transaction.py - _expand_trace function.

If I saw it correct, brownie takes the local compiled files, execute the tests, and trace based on the opcodes.

But there is the following try-except block:

try:
    pc = last["pc_map"][trace[i]["pc"]]
except (KeyError, TypeError):
   # we don't have enough information about this contract
   continue

I was wondering why but I believe that the difference is the bytecode.
If you deploy the following contract to chain:

pragma solidity ^0.8.12;

contract Contract1 {
    uint private i1;

    constructor(uint _i1){
        i1=_i1;
    }

    function getValue() public view returns (uint) {
        return i1;
    }
}

You will be able to get the bytecode from the compiler.
But if you use the immutable keyword in the code:

pragma solidity ^0.8.12;

contract Contract1 {
    uint private immutable i1;

    constructor(uint _i1){
        i1=_i1;
    }

    function getValue() public view returns (uint) {
        return i1;
    }
}

the bytecode deployed as contract differs from the one you get from the Solidity compiler.

If I am wrong about it, let me know :)

Hope it might help the next dev to go deeper.

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

No branches or pull requests

10 participants