-
Notifications
You must be signed in to change notification settings - Fork 1
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
Unify pytezos script #46
Conversation
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 don't like how we've hardcoded minimum confirmation depth to 1. Otherwise LGTM.
main_code = ContractInterface.from_file(zkchannel_contract) | ||
|
||
# Query the blockchain to get the merchant's and customer's public keys | ||
uri = "https://rpc.tzkt.io/edo2net/" |
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.
uri
should be a command-line argument to provide flexibility for sandbox vs testnet
@indomitableSwan. As @jakinyele suggested, now |
cust_pubkey = cust_py.key.public_key() | ||
|
||
# Only require 1 confirmation speed up tests. | ||
min_confirmations = 1 |
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.
same comment as above for min_confirmations
. And 1
might be OK for sandbox but shouldn't testnet config mirror mainnet in terms of requiring 20-30 confirmations?
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.
min_confirmations
and self_delay
can be set as optional arguments now with the default being 1
for both.
As for what min_confirmations
should be set to in tests, I guess it depends on what we are trying to test? I was thinking of this python script as mainly test for the functions that zeekoe will use when calling the entrypoints, making sure they are called successfully (both in terms of how pytezos works and what the contract is expecting). Also bear in mind also there are 18 entrypoint calls in total for the various scenarios, so waiting 1 minute on each call means the test already takes about 18 minutes.
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.
Ok, I see your point. I guess it would be helpful to state the intent here as part of the documentation inside the script? Maybe at the top?
# Only require 1 confirmation speed up tests. | ||
min_confirmations = 1 | ||
# Use a short self_delay so we can test the 'claim' paths without waiting. | ||
self_delay = 1 |
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 self-delay
should be calculated based on whether we're in sandbox or testnet mode right?
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.
same reply as previous comment
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.
Left a few minor comments to address. Thanks!
@jakinyele thanks! I pushed the last change just before your comments, but I also responded to them above. |
Replace pytezos test with a new version that is consistent with how the functions are called in zeekoe.
import the following variables using argparse instead of hard coding: - network (testnet or sandbox uri) - self_delay - min_confirmations
4a88b29
to
17b0704
Compare
17b0704
to
cdd5b4c
Compare
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.
Looks good to me
This PR unifies the pytezos functions we use (/will use) in zeekoe for calling the contract's entrypoints and the previous script (zkchannel_edo2net_broadcaster.py) for testing the various flows on testnet (or sandbox with some adjustments).
The first section of the script defines the functions for calling the entrypoints, and they can be lifted into zeekoe. The rest of the loads the variables from the sample_files directory and runs through various paths of the contract, testing all the entrypoints.
An outstanding issue is returning the
level
for an operation after it is confirmed. Thelevel
for an operation is the block height at which it was included in the blockchain. I think it would make sense for that to be in another PR though. An issue has been created for this #49