-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
Signed-off-by: Jim Zhang <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
There was a problem hiding this 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
@@ -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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
.
There was a problem hiding this 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?
const opts = { | ||
kind: 'uups', | ||
initializer: 'initialize', | ||
unsafeAllow: ['delegatecall'] | ||
}; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good
ff51688
to
f57d353
Compare
Signed-off-by: Jim Zhang <[email protected]>
f57d353
to
f2bf618
Compare
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
There was a problem hiding this 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
Several updates related to testing against a non-hardhat network, as well as public chains.
equal
togte
. 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 networkbefore()
method to accommodate the longer deployment time