grpc
/
grpc-java
mirror of https://github.com/grpc/grpc-java.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Explain why client stub mocking is discouraged (#5796)

This commit is contained in:
Ryan Michela 2019-05-30 08:52:13 -07:00 committed by Kun Zhang
parent bc2e1764f6
commit 9b4c958201
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
examples/README.md
View File

@ -107,6 +107,19 @@ We encourage users to leverage `InProcessTransport` as demonstrated in the examp
write unit tests. `InProcessTransport` is light-weight and runs the server write unit tests. `InProcessTransport` is light-weight and runs the server
and client in the same process without any socket/TCP connection. and client in the same process without any socket/TCP connection.
Mocking the client stub provides a false sense of security when writing tests. Mocking stubs and responses
allows for tests that don't map to reality, causing the tests to pass, but the system-under-test to fail.
The gRPC client library is complicated, and accurately reproducing that complexity with mocks is very hard.
You will be better off and write less code by using `InProcessTransport` instead.
Example bugs not caught by mocked stub tests include:
* Calling the stub with a `null` message
* Not calling `close()`
* Sending invalid headers
* Ignoring deadlines
* Ignoring cancellation
For testing a gRPC client, create the client with a real stub For testing a gRPC client, create the client with a real stub
using an using an
[InProcessChannel](../core/src/main/java/io/grpc/inprocess/InProcessChannelBuilder.java), [InProcessChannel](../core/src/main/java/io/grpc/inprocess/InProcessChannelBuilder.java),