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(test): Integration test to send transactions using lightwalletd #4068

Merged
merged 43 commits into from Apr 27, 2022

Conversation

jvff
Copy link
Contributor

@jvff jvff commented Apr 8, 2022

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

  • Code implements Specs and Designs
  • Tests for Expected Behaviour
  • Tests for Errors

Follow Up Work

  • This test should be added to CI, but it needs an existing cached synchronized chain state to run.

@jvff jvff added P-Medium ⚡ C-testing Category: These are tests A-rpc Area: Remote Procedure Call interfaces labels Apr 8, 2022
@jvff jvff self-assigned this Apr 8, 2022
Copy link
Contributor

@teor2345 teor2345 left a 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.)

zebrad/build.rs Show resolved Hide resolved
zebrad/proto/compact_formats.proto Outdated Show resolved Hide resolved
zebrad/proto/compact_formats.proto Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@teor2345 teor2345 left a 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.

zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
@teor2345 teor2345 added A-dependencies Area: Dependency file updates lightwalletd any work associated with lightwalletd labels Apr 10, 2022
@teor2345
Copy link
Contributor

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.

@teor2345

This comment was marked as outdated.

@jvff
Copy link
Contributor Author

jvff commented Apr 20, 2022

I had an idea about speeding the test up, let me know what you think:

The transactions that we send are going to be the same each time.

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?

@teor2345
Copy link
Contributor

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 🤔

I think this is fine, and we can use the cached tip state.

The cached states should be updated every time we merge to main.

Copy link
Contributor

@teor2345 teor2345 left a 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.)

zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
zebrad/tests/acceptance.rs Outdated Show resolved Hide resolved
@jvff
Copy link
Contributor Author

jvff commented Apr 22, 2022

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 zebrad/tests/common/lightwalletd/send_transaction_test.rs sub-module. Then I could have the main test function in acceptance.rs be simply a "jump function" (i.e., it would simply call the test function inside that new sub-module). What do you think?

@teor2345
Copy link
Contributor

teor2345 commented Apr 22, 2022

One option might be to create a zebrad/tests/common/lightwalletd/send_transaction_test.rs sub-module. Then I could have the main test function in acceptance.rs be simply a "jump function" (i.e., it would simply call the test function inside that new sub-module). What do you think?

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 acceptance.rs or its own module would be fine.

This isn't a merge blocker, we can always work it out later.

teor2345
teor2345 previously approved these changes Apr 26, 2022
Copy link
Contributor

@teor2345 teor2345 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 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.

zebrad/tests/common/lightwalletd/rpc.rs Outdated Show resolved Hide resolved
teor2345
teor2345 previously approved these changes Apr 26, 2022
Copy link
Contributor

@teor2345 teor2345 left a 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?

@jvff
Copy link
Contributor Author

jvff commented Apr 26, 2022

Looks good, just wondering if my build script suggestion worked?

Sorry, I think I missed something. What build script suggestion? 😅

@oxarbitrage
Copy link
Contributor

Ill probably move some code in send_transaction_test.rs into a generic file and maybe just keep the run() there as i am creating tests that use the same utility functions but do different rpc calls.

@teor2345
Copy link
Contributor

Looks good, just wondering if my build script suggestion worked?

Sorry, I think I missed something. What build script suggestion? 😅

This optional suggestion:
#4068 (comment)

@teor2345
Copy link
Contributor

It's ok to ignore the duplicate heck dependency by updating deny.toml.

@teor2345
Copy link
Contributor

@Mergifyio update

jvff added 17 commits April 27, 2022 02:46
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.
deny.toml Outdated Show resolved Hide resolved
Copy link
Contributor

@teor2345 teor2345 left a 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

@jvff jvff requested a review from a team as a code owner April 27, 2022 18:10
Copy link
Contributor

@teor2345 teor2345 left a 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.

mergify bot added a commit that referenced this pull request Apr 27, 2022
@mergify mergify bot merged commit 5a94a09 into main Apr 27, 2022
@mergify mergify bot deleted the send-transaction-lightwalletd-test branch April 27, 2022 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependencies Area: Dependency file updates A-rpc Area: Remote Procedure Call interfaces C-testing Category: These are tests lightwalletd any work associated with lightwalletd
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Send transactions in lightwalletd integration tests
4 participants