Hello all! I'm looking for some guidance on approa...

# ktor

[Adam Papenhausen]

Hello all! I'm looking for some guidance on approaches to unit testing Ktor client plugins. We use Hilt for the DI layer and I'm having trouble reasoning about the best way to wrap the Ktor plugin for testing. For instance, take the following OkHttp interceptor:

/** Adds the package name as headers for every request. */
class BuildMetadataMiddleware @Inject constructor(private val packageInfoProvider: PackageInfoProvider) : Interceptor {
  companion object {
    const val ClientNameHeader = "X-Client-Name"
  }

  override fun intercept(chain: Interceptor.Chain): Response = chain.proceed(
    chain.request().newBuilder()
      .addHeader(ClientNameHeader, packageInfoProvider.packageName)
      .build()
  )
}

I can then create a test client and assert on the intercept method with a fake PackageInfoProvider. With Ktor, it doesn't immediately seem that you want to subclass the ClientPlugin interface but rather provide a plugin config class, which to my understanding requires a default value. I have two questions:
• How can I implement this if I do not want a default value (always have it be provided by the injected dependency)
• How can a plugin fail safely? Would I need to create custom exceptions and handle them or is there an API like request.cancel(reason) ?
This is what the above impl could look like in Ktor:

class BuildMetadataConfig {
  val packageName: String? = null
}

val buildMetadataPlugin = createClientPlugin("BuildMetadata", ::BuildMetadataConfig) {
  val packageName = pluginConfig.packageName

  onRequest { request, _ ->
    request.header("X-Client-Name", packageName)
  }
}

[Aleksei Tirman [JB]]

So do you want to test that the client with the installed plugin sends the X-Client-Name header on each request?

[Adam Papenhausen]

Yes, but also that it can pull the value of the header dynamically from a dependency on every request.

[Aleksei Tirman [JB]]

Do you mean that the header value is configurable?

[Adam Papenhausen]

In this case just the header value, which is provided by a PackageInfoProvider interface that gets injected where the client is created

[Adam Papenhausen]

For example, I think one way to make the abstraction is like this:

val buildMetadataPlugin = fun(packageInfoProvider: PackageInfoProvider) = createClientPlugin(...)

[Aleksei Tirman [JB]]

You can test the plugin using the MockEngine (https://ktor.io/docs/http-client-testing.html).

[Adam Papenhausen]

Okay, for the other part of my question, if a client's plugin fails, is it recommended to throw an exception and catch it where the request was made or is there a different recommended approach to cancelling/failing a request?

[Aleksei Tirman [JB]]

What kind of failure are you talking about?

[Adam Papenhausen]

Let's say for instance I have a plugin that tries to encode some data in the request body as JSON but the encoding itself fails. Or, it tries to read a header value (like in the example above) from a cache/db but it is not there. I want to short-circuit the request and be able to catch the failure. In OkHttp the way to do that is by throwing an exception - wondering if Ktor has a different approach?

[Adam Papenhausen]

Or is it better that plugins do not handle these types of failure modes?

[Aleksei Tirman [JB]]

In case of failure, you can throw an exception, and so the execution context of the request will be canceled with the reason.