Replies: 1 comment 3 replies
-
Ethers respects the standard json rpc methods. You can have a look at this resource. Contract read functions uses eth_call rpc and write function use eth_signTransaction rpc (you can have a json rpc signer). Feel free to just mock the RPC (while using aa JsonRpcProvider) or just write a custom provider class that implements ethers.providers.Provider and use it in your tests. It is possible that it could be a lot of work to setup the rpc mocking, so if your contracts are complex and you're short on time, going through the hardhat network path can possibly be easy to build. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Problem
If you want to run a unit test on a frontend component that retrieves data from a smart contract via RPC and executes some logic based on that data, you currently have a few options (this list is probably not exhaustive but just exemplary of current pain points):
Spin up a local node (using Geth or hardhat potentially?)
Pros:
Cons:
Mock RPC response. This might look similar to how you would mock a call to a remote API in a web2 context.
Pros:
Cons:
Solution
Easily enable mocking responses from smart contracts called by ethers.
At a high level, when you instantiate a Contract on your frontend, some logic is executed in the Contract constructor to set up methods in the contract based on the ABI you passed in. If we mock the Contract prototype in our unit test, we lose some validation that we are interfacing with the Contract class correctly; i.e. breaking changes in our ABI may not be caught.
Some possible solutions are:
Beta Was this translation helpful? Give feedback.
All reactions