You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
E.g., TraceServiceClient has all of the methods marked as final. Thus it's impossible to use with Mockito. There is no interface to mock either. This makes it hard to test higher level libraries that needs to consume our client/stubs.
Personally I'm not a big fan of final methods and classes. So I'm fine with removing final from our generated clients, and I support the mocking argument. I don't know why it was decided to make a non-final class with all-final methods in it (does it even make sense?).
Adding an interface to the client so the interface can be mocked is also fine, but it will be more work and more complexity. It will be potentially generating more boilerplate code with no real benefits (the only potential benefit I see here is this will allow to have, for example, 2 different transport implementations for same client: gRPC and, for example, REST).
I think not allowing to mock our clients is a big issue (mocking networking part is a very often case in unit testing, so our current situation means that everybody who is using our clients will not be able to write proper unit tests for their code). Changing priority from P2+ to P1.
The reason for final is to reduce the number of places where users could break when we make breaking changes.
The title of this issue isn't fully correct: There isn't anything final on the stubs. I think the right way to mock is to create a stub, and pass that to the client when constructing it. The client is really just a thin passthrough to the stub anyway.
Activity
[-]Stubs cannot be mocked[/-][+]Clients / Stubs cannot be mocked[/+]shinfan commentedon Sep 14, 2017
I think this is an issue affecting all auto-gen clients.
@vam-google What are your thoughts on this?
vam-google commentedon Sep 14, 2017
Personally I'm not a big fan of final methods and classes. So I'm fine with removing
finalfrom our generated clients, and I support the mocking argument. I don't know why it was decided to make a non-final class with all-final methods in it (does it even make sense?).Adding an interface to the client so the interface can be mocked is also fine, but it will be more work and more complexity. It will be potentially generating more boilerplate code with no real benefits (the only potential benefit I see here is this will allow to have, for example, 2 different transport implementations for same client: gRPC and, for example, REST).
@garrettjonesgoogle what is our opinion about it?
vam-google commentedon Sep 14, 2017
I think not allowing to mock our clients is a big issue (mocking networking part is a very often case in unit testing, so our current situation means that everybody who is using our clients will not be able to write proper unit tests for their code). Changing priority from P2+ to P1.
garrettjonesgoogle commentedon Sep 20, 2017
The reason for
finalis to reduce the number of places where users could break when we make breaking changes.The title of this issue isn't fully correct: There isn't anything
finalon the stubs. I think the right way to mock is to create a stub, and pass that to the client when constructing it. The client is really just a thin passthrough to the stub anyway.yihanzhen commentedon Jan 18, 2018
Moving this issue to feature request backlog.
Fix: Fix issue where Universe Domain is not correctly set. (#2423)
chore(main): release 3.3.0 (#2415)
chore(main): release 2.35.0 (#2423)
chore: Update generation configuration at Sun May 11 02:34:28 UTC 2025 (
chore: Update generation configuration at Sun May 11 02:34:28 UTC 2025 (