-
Notifications
You must be signed in to change notification settings - Fork 419
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
Generate ClientCallUnary test stubs. #398
Conversation
This simplifies testing for async calls, e.g. a failing request could be simulated with something like: ``` override func get(_ request: Echo_EchoRequest, metadata customMetadata: Metadata, completion: @escaping (Echo_EchoResponse?, CallResult) -> Void) throws -> Echo_EchoGetCall { completion(nil, .error(statusCode: .notFound)) return Echo_EchoGetCallTestStub() } ```
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 how I wanted to avoid having to create an unused Channel
in
#378 (see my review of that PR). That PR needs a few more cleanups; afterwards stubbing async calls should be fully supported.
@@ -56,3 +56,10 @@ open class ClientCallUnaryBase<InputType: Message, OutputType: Message>: ClientC | |||
return self | |||
} | |||
} | |||
|
|||
/// Simple fake implementation of `ClientCallUnary`. | |||
open class ClientCallUnaryTestStub<InputType: Message, OutputType: Message>: ClientCallUnary { |
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.
Does this need to be generic at all?
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 strictly necessary at the moment, was primarily going for consistency with ClientCallClientStreamingTestStub
. The generics would be necessary if we want similar request queueing or response recording, thought TBH I find that approach a bit to constrained for my use-cases. In unit tests I'd generally want to test a lot of error cases and in integration tests I'd generally want the stub to have business logic (as in, I really want an in-memory fake).
I don't have strong preferences regarding the generics, let me know if you'd prefer I remove them. Happy to update the PR either way.
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 the elaboration! For now, let's remove them; I'm open to re-adding them later on if necessary.
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.
Done.
This simplifies testing for async calls, e.g. a failing request could
be simulated with something like: