-
Notifications
You must be signed in to change notification settings - Fork 111
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
Use MockedClientHandle
in other tests
#3241
Conversation
412d1e9
to
73cf624
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.
This is a good idea, but we have to be careful that we don't reduce actual peer::Client
test coverage.
73cf624
to
56dc0ba
Compare
56dc0ba
to
8ef552f
Compare
I changed how the initialization is done to use a
|
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 sorry for the misunderstandings in my last review, I found these changes really confusing.
I have a bunch of suggestions for improving the documentation and names in this PR.
We might also want to improve the corresponding peer::Client
and peer::Connection
documentation, because it is outdated.
This is a low priority by itself, but #3253 depends on it, so I've marked it as medium. |
It's more closely related to a `Client` than the `PeerSet`, and this prepares it to be used by other tests.
Reduce confusion, and clarify that the client is not mocked. Co-authored-by: teor <[email protected]>
Explicitly say how the generated data is returned.
The `Client` service only represents one direction of a connection, so `is_connected` is not the exact term. Co-authored-by: teor <[email protected]>
Move where the conversion from mocked `Client` to mocked `LoadTrackedClient` in order to make the test helper more easily used by other tests.
Replace the boilerplate code to create a fake `Client` instance with usages of the `ClientTestHarness` constructor.
Create a helper type to wrap the result, to make it easier to assert on specific events after trying to receive a request.
Share the `ErrorSlot` between the `Client` and the handle, so that the handle can be used to inspect the contents of the `ErrorSlot`.
Assuming it is initially empty. If it already has an error, the code will panic.
Close the endpoint with the appropriate call to the `close()` method.
Forcefully closes the endpoint.
Also rename the related methods to include `outbound_client_request_receiver` to make it more precise. Co-authored-by: teor <[email protected]>
Allows the `Client` to detect that the channel has been closed.
Avoid negated method names. Co-authored-by: teor <[email protected]>
Checks if a `Service` is not ready to be called.
Reduce repeated code and try to improve readability.
A builder to create test `Client` instances using mock data which can be tracked and manipulated through a `ClientTestHarness`.
Add a `with_version` builder method.
Use the builder to set the peer version, so that the `version` parameter can be removed from the constructor later.
Reduce noise when setting up the harness for tests that don't really care about the remote peer version.
The `with_version` builder method should be used instead.
c174644
to
057d162
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 happy with this PR, but I'd like to merge the fixes in PR #3262 soon as well.
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.
In #3262 (comment) @jvff said:
Doing the assertion last is also not ideal, since some assertions require the client instance to be polled first.
Do these requirements apply to all Client
s, or only to ClientTestHarness
?
This isn't a blocker, but it would be nice to document these requirements as part of this PR. (They were a bit of a surprise to me.)
PR #3273 might help clarify these requirements. If I'm using the |
And document existing tests.
Sorry I wasn't clear. I meant that doing it last would mean that we wouldn't be asserting on the correct things. We would assert things before
Looks good to me 👍 |
* Replace NowOrLater with the futures::poll! macro in zebrad * Replace NowOrLater with the futures::poll! macro in zebra-test * Remove the now-or-later crate
…dle-in-other-tests
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 we're all done here!
Motivation
While adding a field to the
Client
type, I realized I would have to add a dummy instance of the field to many mock client instances in tests. Since I had written aMockedClientHandle
for some other tests, I wondered if I could use that in the other tests so that I would only need to update one place later.Solution
I moved the
MockedClientHandle
to another module to make it easier to find, and also extended it to perform the operations the other tests required. I ended up trying to refactor those tests a bit to try to improve readability.Review
@teor2345 recently wrote some of the changed tests.
Reviewer Checklist