-
Notifications
You must be signed in to change notification settings - Fork 108
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(test): Integration test to send transactions using lightwalletd #4068
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.
This looks like a good design, and it seems to do what we want it to do.
I have some suggestions to make sure the tests are correct and easy to understand.
(The performance questions are not as important.)
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 just checked this test against the existing lightwalletd_integration
test.
I have a few more suggestions to increase test coverage and reliability.
I've added a bunch of different comments to this PR, let me know if you want to do a video catch up to work through any of them. |
This comment was marked as outdated.
This comment was marked as outdated.
I was actually aiming to not have the same transactions every time 😅 My goal was to use real diverse transactions from the Zcash chain, and my assumption was that the cached state of the full synchronization test would be updated more frequently. Something like being updated every day or so 🤔 But I agree using test vectors would be simpler. I'm not sure how to build test vectors with a good coverage though :/ Or maybe we just want a few simple transactions? |
I think this is fine, and we can use the cached tip state. The cached states should be updated every time we merge to |
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 great!
If we want to make the environmental variable names consistent, we should do it now, because we'll use them on the DevOps side.
Otherwise I'm happy to merge this, and we can do cleanups, fixes, and refactoring later. (I'd like to re-use some of the utility functions in the full sync test.)
I'd like to move the utility functions to a sub-module, but I don't know which 😅 My initial thought was to create a new module for all of the send transaction test functions (utility functions and the main test function), but I wonder if that might make the test hard to find 🤔 One option might be to create a |
Based on our planned integration tests, I think it might be useful to have:
I don't mind what we do with the sendrawtransaction-specific code, as long as we keep it together. Either in This isn't a merge blocker, we can always work it out later. |
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 these changes, I think everything that's left over is optional.
Feel free to resolve all the comments and merge.
Or anyone should feel free to re-review after any changes.
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, just wondering if my build script suggestion worked?
Sorry, I think I missed something. What build script suggestion? 😅 |
Ill probably move some code in |
This optional suggestion: |
015ae07
to
d5db500
Compare
It's ok to ignore the duplicate |
@Mergifyio update |
Speed up the initialization of the Zebrad instance used for lightwalletd to connect to.
Document how the environment variable can be used to speed up the test.
Enable checking for known process failure messages.
Document why it exists and how the choice of the value affects the test.
And use it for the Zebrad and the Lightwalletd instances used in the send transaction integration test.
Enable checking the lightwalletd process for known failure messages.
Use the latest version and fix CI failures because `rustfmt` isn't installed in the build environment.
Move the send transaction using lightwalletd test and its helper functions into a new module.
Place it in the parent `lightwalletd` module.
Make them more accessible so that they can be used by other tests.
Move the test utility functions related to using a cached Zebra state into the module.
Keep to closer to the synchronization utility functions.
Place it in the `cached_state` module.
Make it part of the set of tests ignored as a whole if no lightwalletd tests should be executed.
Place it in the `launch` sub-module.
Avoid any potential misunderstandings when the name is seen out of context.
At least until `structopt` is updated or `zebra-utils` is updated to use `clap` 3.
432a1a1
to
6c34231
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.
I'm not sure what's going on, seems like cmake
is missing now?
https://github.com/ZcashFoundation/zebra/runs/6186747677?check_suite_focus=true#step:9:1631
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!
prost
is a dev dependency, socmake
is only needed for the tests. (The locked release build is on a GitHub runner without protobuf, and it works without these changes.)
So we don't need to update the README to list these new requirements.
Motivation
Zebra's current lightwalletd integration test does not cover some RPCs. These RPCs should be covered by extra tests.
Solution
Add an integration test that sends some valid transactions to Zebra using lightwalletd. These transactions are obtained from a valid block in the Zcash chain that the Zebra instance doesn't have. In order to prevent the Zebra instance from downloading that block, it is started with an existing partially synchronized chain and does not have any network connections, so it can't extend that chain.
Closes #3512.
Review
This is still in a draft stage because
Reviewer Checklist
Follow Up Work