Optionally generate Client Stubs

[octonato]

The idea is to let the codegen generates clients stubs for tests freeing users from defining it by hand. Especially useful for services with many many methods.

There are two types of stubs that can be generated. One that throws exceptions and one that always returns the default instance of the return message.

object SomeApiClientStub {

  trait Unimplemented extends SomeApiClient {
    def someRpc(in: SomeRpcRequest): Future[SomeRpcResponse] = ???
  }

  trait Empty extends SomeApiClient {
    def someRpc(in: SomeRpcRequest): Future[SomeRpcResponse] = Future.successful(SomeRpcResponse.defaultInstance)
}

The users could then override only the methods they are interested in for their test leaving the others simply untouched.

[johanandren]

Throwing sounds like the path to go to me. I can't think of any benefits from returning an empty default response message in a test scenario?

[alexklibisz]

I opened the original Lightbend support ticket requesting this. Thanks for opening here.

I think just throwing is fine. I'm trying to think why we used the Empty pattern, and can't remember a compelling reason. I just tried replacing Empty with Unimplemented in a couple places and it works fine.

One more consideration: in some cases we've also found it useful to have an object and/or method as follows:

object SomeApiClientStub {

  trait Unimplemented extends SomeApiClient {
    def someRpc(in: SomeRpcRequest): Future[SomeRpcResponse] = ???
  }

  object Unimplemented extends Unimplemented

  def unimplemented: SomeApiClient = new Unimplemented
}

This will be extremely helpful for reducing boilerplate in test suites. Thanks :)

[alexklibisz]

It might also be useful to throw a custom exception, roughly, final class AkkaGrpcStubNotImplementedException extends NotImplementedError, to make it more obvious that a stubbable, unimplemented method was called.