Solidity-coverage: Support HardHat

Created on 14 Oct 2020  路  6Comments  路  Source: sc-forks/solidity-coverage

  • [ ] #540
  • [ ] Run BuidlerEVM via buidler 619
  • [ ] Update Buidler E2E test
  • [ ] Use BuidlerPluginError (see #527)
  • [ ] Speed up initialization by lazy loading & using ethers instead of web3
0.7.0 Buidler

Most helpful comment

Looking forward to this!

All 6 comments

Looking forward to this!

0.7.12

See the new Hardhat README for installation instructions, etc.

By default coverage now runs on the HardhatEVM / network and requires no additional config or ganache provider setup. Also about 2X faster.

Please just lmk if you run into any issues with this.

Amazing! I upgraded to 0.7.12 in my [solidity-template][1] and it works like a charm with Hardhat. Thanks @cgewecke!

https://github.com/PaulRBerg/solidity-template

Hi,
This does work great unless you have set a different path for artifacts in hardhat.config.{js,ts}.

For example in my repo I have

  paths: {
    cache: "./build/cache",
    artifacts: "./build/artifacts",
  },

So with still the tests fail unless I run with hardhat coverage --temp build/artifacts since I'm also using the hardhat-typechain plugin which reads from the artifacts path.

I think the right thing to do here is for the plugin to have the artifacts be stored in the paths.artifacts path instead of the hardcoded .coverage_artifacts path

This is an example repo with this config: https://github.com/unipeer/unipeer

Hi @shalzz, thanks for reporting.

Yes, I think at a minimum the README needs to highlight this option and discuss how to use w/ typechain or other plugins that also rely on the paths.artifacts value.

The difficulty with storing coverage artifacts in the default location is that they are "corrupted" by the instrumentation the tool adds to the solidity code. And it's possible people rely on the artifacts folder being preserved across commands and would be upset when coverage automatically deletes it.

Additionally, there is a bug discovered yesterday in the way paths.artifacts is set/read (#573) which I've cross-reported at hardhat 1030. Am waiting for advice about how to proceed there...

Hi @cgewecke

Yes that makes sense, I think the if #573 is fixed it should also address this issue, since then typechain can then just read the instrumented artifacts from the temp folder set by this plugin.

In any case thanks a lot for the plugin.

Was this page helpful?
0 / 5 - 0 ratings