Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add conditions around solidity failure cases for hardhat network only #46

Merged
merged 8 commits into from
Aug 28, 2024

Conversation

jimthematrix
Copy link
Contributor

@jimthematrix jimthematrix commented Aug 23, 2024

Several updates related to testing against a non-hardhat network, as well as public chains.

  • group together the failure tests and add a condition to skip when the target network is not hardhat. this is because the detailed error messages are only returned by hardhat, but not other types of EVM networks (would just be the generic "EVM transaction reverted")
  • change the balance checking after deposit and withdraw from equal to gte. This doesn't impact runs against the hardhat network. Ignition only does the caching of the deployed contracts, to save on gas apparently, when deploying against a non-hardhat contract. So the change to check on greater than or equal to is equivalent to equal to when running against the hardhat network, but will avoid test failures when running against non-hardhat network
  • specifically for public networks, increasing the timeout of the before() method to accommodate the longer deployment time

Copy link

codecov bot commented Aug 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.11%. Comparing base (3b7a354) to head (fcf39b6).
Report is 12 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
+ Coverage   73.23%   78.11%   +4.88%     
==========================================
  Files          12       13       +1     
  Lines         538      553      +15     
==========================================
+ Hits          394      432      +38     
+ Misses        103       83      -20     
+ Partials       41       38       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@Chengxuan Chengxuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jimthematrix I like the intention of reusing existing tests to drive public network testing.

However, I feel we should preserve the same level of checks and behaviors for running local tests where possible. I added a few comments from that angle.

As the testing against a non-hardhat network is not part of the automated pipeline, preventing it from deteriorating is another problem to consider, but might not be an immediate concern.

solidity/test/zeto_anon.ts Outdated Show resolved Hide resolved
@@ -64,7 +61,7 @@ describe("Zeto based fungible token with anonymity without encryption or nullifi
const tx = await erc20.connect(deployer).mint(Alice.ethAddress, 100);
await tx.wait();
const balance = await erc20.balanceOf(Alice.ethAddress);
expect(balance).to.equal(100);
expect(balance).to.be.gte(100);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel we shouldn't sacrifice the scope of assertions in the tests when running against a hardhat network.

Copy link
Contributor Author

@jimthematrix jimthematrix Aug 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't impact runs against the hardhat network. Ignition is pretty smart, it only does the caching of the deployed contracts, to save on gas apparently, when deploying against a non-hardhat contract. So the change to check on greater than or equal to is equivalent to equal to when running against the hardhat network.

Here's the abridged output from runs against the hardhat network, you can see the ERC20 contract is re-deployed for every test suite:

  Zeto based fungible token with anonymity without encryption or nullifier
Deploying as upgradeable contracts
ZetoToken deployed: 0x5FC8d32690cc91D4c39d9d3abcBD16989F875707
ERC20 deployed:     0x5FbDB2315678afecb367f032d93F642f64180aa3
...
  Zeto based fungible token with anonymity and encryption
Deploying as upgradeable contracts
ZetoToken deployed: 0x9A9f2CCfdE556A7E9Ff0848998Aa4a0CFD8863AE
ERC20 deployed:     0xA51c1fc2f0D1a1b8494Ed1FE312d7C3a78Ed91C0
...
  Zeto based fungible token with anonymity using nullifiers and encryption
Deploying as upgradeable contracts
ZetoToken deployed: 0x84eA74d481Ee0A5332c457a4d796187F6Ba67fEB
ERC20 deployed:     0xa85233C63b9Ee964Add6F2cffe00Fd84eb32338f

On the other hand, making this change avoids failures in testing against a non-hardhat network, because the same ERC20 contract is used for all test suites, due to ignition layer caching.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if the smart contract accidentally doubled the amount in the transfer logic, this check will throw an error because it knows it's running in Hardhat mode, therefore, gte need to be switched to equal?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I understand the question @Chengxuan ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the best way to address the concern of missing implementation errors like you pointed out before, without sacrificing public chain testability (where the ERC20 contract is re-used across the test suites due to ignition caching), is querying for the starting balance and ending balance around the Zeto operation. This way we can change back the check to equal.

Copy link
Contributor

@EnriqueL8 EnriqueL8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with the concerns from @Chengxuan on making sure we have a reliable set of tests against a non-hardhat setup and we don't hide issues by simply extending the timeouts.

Could you also provide a description in this PR?

Comment on lines -11 to -15
const opts = {
kind: 'uups',
initializer: 'initialize',
unsafeAllow: ['delegatecall']
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we needed this for upgradable contracts?

Copy link
Contributor Author

@jimthematrix jimthematrix Aug 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's accurate that this options object is needed for upgradeable contracts, but here we are deploying the implementation contract that can then be cloned, so no need for these parameters.

What we could do is, demonstrate how the cloned instance can then be turned into an upgradeable contract. But that's making the sample too complex (first deploy the implementation, then deploy the clone factory, then create the clone, and then make it into an upgradeable).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good

solidity/test/zeto_anon.ts Outdated Show resolved Hide resolved
Signed-off-by: Jim Zhang <[email protected]>
Copy link
Contributor

@Chengxuan Chengxuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing the comments. @jimthematrix

@Chengxuan Chengxuan merged commit f9b4a17 into main Aug 28, 2024
5 checks passed
@Chengxuan Chengxuan deleted the public-chains branch August 28, 2024 04:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants