Recommended Test Setup with OZ SDK

General
1

Hi,

What is the current recommended test setup for the OZ SDK. From the docs it looks like truffle is still the way to go. However, the mixing of the oz SDK with truffle does not look too neat to me.
Is there already a testing framework that is built into the oz SDK? If not, are there plans to roll one out soonish?

3 Likes
2

Stay tuned :sunglasses:

We will be making an announcement real soon!

3 Likes
3

I haven’t yet fully switched to OZ SDK for that reason. Still preferring truffle just because it provides a test framework.
Also it would be great if you could enrich you documentation on OZ command line; more examples, more explanations, etc.

1 Like
4

Hi @gitpusha,

Great timing with this question!
There are definitely plans for an OpenZeppelin test environment.

In fact the repository for this has just been made public.

Please note, it hasn’t been formally announced (this will be coming soon-ish), so it is a soft launch for now.

Feedback on using the framework is greatly appreciated.

OpenZeppelin Test-Environment

2 Likes
5

Hi @bayram,

There is now an OpenZeppelin Test-Environment!

Please note, it hasn’t been formally announced (this will be coming soon-ish), so it is a soft launch for now.

Feedback on using the framework is greatly appreciated.

OpenZeppelin Test-Environment

For OpenZeppelin CLI documentation, can you give more detail on what you would like to see regards examples and documentation, so that we can make it more useful.
Are there particular commands you would like more information on?

2 Likes
6

Hi @spalladino and @abcoathup. Too much tease, so many questions:
Does oz test environment work well with tools like + how to configure?

  • solidity-coverage
  • eth-gas-reporter

Is there built-in ethers.js support too?

2 Likes
7

Hello @gitpusha, thanks for your interest in test-environment! Keep in mind this is only an initial release, in which we’re focusing on more simple setups that are limited to running tests. That said, we’ve definitely considered those tools during the design of test-environment, and plan to add first-class support for them soon.

solidity-coverage actually already has experimental, undocumented support which is used in the OpenZeppelin Contracts build. Since a new, much better version of coverage is coming out soon, we’re holding off the integration until that happens. You can read more about that and share ideas on this issue: https://github.com/OpenZeppelin/openzeppelin-test-environment/issues/21

Regarding ethers, we expose a provider object which is a regular web3 provider: you should be able to use it to set up your ethers instance like in any other development setup. You could do something similar to create Contract objects. Are there any specific ethers features you’d like to see being supported natively?

3 Likes
8

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.

Regarding 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?

Regarding 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 web3.js to 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 web3.js and 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

contracts: {
   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 ethers.js?
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?

1 Like