How is solidity-coverage integrated into OpenZeppelin

I recently started to use solidity-coverage and I wanted to confirm a few things regarding the way you integrated it in @openzeppelin/contracts-ethereum-package.

  1. Are you using a fork of ganache-cli(@frangio’s ganache-cli-coverage) primarily because you have to pre-fill some specific ethereum accounts with a lot of ether (>1m) in scripts/ Or are there more reasons?

  2. In testCommand and compileCommand in .solcover.js, you’re setting --max-old-space-size=4096. Why?

  3. Are there any plans to migrate to a different set up? Is it safe to “fork” your integration now?

Thank you!


Hi @PaulRBerg,

This is the reason I could find, though I don’t know if this is still an issue:

I haven’t found the answers to 1 and 3 (yet).

1 Like

No, the ability to define the accounts and their balances is already present in upstream ganache-cli.

The way that solidity-coverage was implemented required changes in ethereumjs-vm, and that implied changes in ganache-cli, which uses the former. This ended up propagating as changes in all of these packages, which gave the name to the sc-forks GitHub org. The project was abandoned for a while and that’s why we had to create our own fork to update it with support for some of the new opcodes (from Byzantium I think).

I believe the original developer of solidity-coverage is working on a new version that will not require all of these forks, and we will probably migrate to that as soon as it’s usable. The current setup is a pain to maintain. It’s safe to use it, in fact it probably has the most features among the alternatives, but it can be a painful experience if something doesn’t work. :cold_sweat:


This sounds :exploding_head:

Yup! I ended up exchanging loads of messages in the meantime and it seems version 0.7.0 will be much more stable and easy to use.

Unfortunately, it hasn’t been for me. I defaulted to using the latest version of solidity-coverage (0.6.5) and ethereumjs-testrpc-sc (6.5.1-sc.0). That worked, but to be fair it still feels hack-ish.

Bottom line, this looks like something that the Ethereum community as a whole should spend more time (and money) on.