Clients / Stubs cannot be mocked

[saturnism]

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.

[shinfan]

I think this is an issue affecting all auto-gen clients.

@vam-google What are your thoughts on this?

[vam-google]

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).

@garrettjonesgoogle what is our opinion about it?

[vam-google]

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]

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.

[yihanzhen]

Moving this issue to feature request backlog.