Does openzeppelin-test-environment support other clients?

[shd101wyy]

Does openzeppelin-test-environment support other clients such as Parity, Geth, cpp-ethereum, etc.
Thank you!

[ehildenb]

Related to #20.

We need this feature so that we can use our instrumented client for running tests instead of ganache-cli (we collect extra data with our client that we use for quality assurance purposes).

Would it be possible to expose an option for selecting the client? In our case, we've made sure our client is argument-for-argument compatible with ganache-cli, so all we need to do is replace the call to ganache-cli with a call to our binary.

[frangio]

We have considered supporting other clients before, but one of the main things Test Environment does is set up the accounts for Ganache, in a way that doesn't look simple or even possible to do with other clients. This means that the current design is quite coupled to Ganache itself, so it would require considerable effort to support other clients at the moment.

@ehildenb Note that we are using ganache-core rather than ganache-cli, so I don't think the simple change you suggest would work.

[ehildenb]

Well I think there is a lot of benefit to supporting any web3 client, because ganache-core is not likely to continue to have all the debugging features you need.

Can you shed more light on this statement? "but one of the main things Test Environment does is set up the accounts for Ganache, in a way that doesn't look simple or even possible to do with other clients"

What type of setup does it do? Maybe we can do the same with our client.

[frangio]

If your client is based on Ganache it's probably also possible for Test Environment to use it. It just wouldn't be a one-line change.

The issue with accounts is that they're generated synchronously so that they can be available at the top level of a file (since they don't require await). The code is in accounts.ts. If it's possible to provide private keys to initialize a client's accounts, it should be possible to use it.

[ehildenb]

We do have a mechanism for providing the private keys for accounts directly over RPC. Our client is not based on ganache, it's completely separate, but we've made it command-line compatible with ganache-cli in the hopes that other testing tools would be able to integrate our client directly and benefit from the extra information we collect.

Is the account initialization the only step that would be tricky for switching out the underlying client used? In our case, that boils down to sending a sequence of firefly_addAccount ... RPC messages with the private keys.

BTW, we are working on the Firefly client: https://fireflyblockchain.com/

[frangio]

If it's done via RPC it could likely be done since it's a similar architecture to what we're doing with Ganache in Test Environment. I can't think of other complications that might show up.

While I'd encourage you to fork the library and set it up, I can't guarantee that we'll be able to merge it back and support it by default.

[wenhaosu]

@frangio Hi! I'm from team Firefly, and currently as you've encouraged, we are investing in forking this library and trying to add support for other clients including Firefly. May I get some hint on which part of the code should we look into, try to modify and get this feature added?

[frangio]

@wenhaosu I think you want to look at ganache-server.ts and/or setup-ganache.ts.

[wenhaosu]

@frangio Thanks for the reply! In ganache-server.ts I've noticed that there is a code block for ganache server to set up and listen to a free port. May I ask whether there is a way to run the Test Environment from CLI so that we can test sending RPC to the port ganache-core server is listening on?

[frangio]

@wenhaosu Test Environment was deliberately designed as a library so there is no CLI.