Hi @nventuro. Thanks for the detailed response. I will start playing around with
test-environment myself. I think it is worth doing so and waiting for the upcoming releases, as I am just impressed with the developer experience your products have provided me with so far. So might as well start using it now, and spare me switching my suite over to it later, once the full-fledged release is there.
solidity-coverage and OpenZeppelin/openzeppelin-test-environment#21 - it sounds a bit like I should stay away from
jest/ava if I want to rely on
solidity-coverage working well for me in the near future. Or is a solution to your issues imminent?
ethers - I will have to report back to you, once I fiddled around wih it inside the
test-environment . I only recently made the switch from
ethers.js and found the latter much more pleasing and less verbose. I also prefer the
ethers.js docs . I guess (for me) the
test-environment would ideally be designed with
ethers.js in mind too. But I know you guys use
web3.js and more people seem to use that still. Actually, I have heard that the EF wants to combine the teams working on
ethers.js under a unified effort. So maybe there’s some new library altogether to come soon anyway.
One question from the top of my head:
The code inside the test-environment.config.js file
type: 'truffle', // Contract abstraction to use: 'truffle' for @truffle/contract or 'web3' for web3-eth-contract
defaultGas: 6e6, // Maximum gas for contract calls (when unspecified)
What would I do for the
type field, if I used
I guess with some more thinking, I’d figure it out myself. It’s just that ideally it would be covered in the
test-environment docs for ethers.js users like me. But dont worry bout it please, if it’s not on your priority list.
May I also add: do you have any experience with
ethers.js, and any opinions on it?