Create a test artifact to help with testing code that depends on connect-kotlin generated code

[erawhctim]

When testing code that has a dependency on one of the API clients/endpoints that connect-kotlin generates, consumers have to rely on mocking frameworks to stub out the generated calls and replace their responses.

This generally works, due to the maturity of mocking frameworks on the JVM, but as an alternative (for projects that don't want to import/use mocking frameworks), buf/the BSR could generate fake API client implementations for testing purposes (similar to how the connect-swift-mocks plugin works).

[ln-12]

Hey @erawhctim, did you find a suitable approach to mock the dependency yet?

I will probably do it by implementing the methods from the generated client interfaces using my mock data and provide these implementations via dependency injection instead of the actual client implementations. Just wanted to know if you maybe found another approach.

[erawhctim]

Hey @erawhctim, did you find a suitable approach to mock the dependency yet?

I will probably do it by implementing the methods from the generated client interfaces using my mock data and provide these implementations via dependency injection instead of the actual client implementations. Just wanted to know if you maybe found another approach.

Sorry for the late reply here! Your solution matches ours: we're using overloaded constructors that allow us to supply a mocked instance of the generated client in tests, while injecting the ProtocolClient and manually constructing those client instances instead.