Add Integration Testing with Ktor Client and Server in Kotlin Multiplatform

[kez-lab]

Hello,

I’ve been delayed in submitting this Pull Request due to other pressing tasks. However, I am now submitting a PR inspired by the excellent advice from the Ktor team regarding integration testing.

The current test cases are kept at a basic level for simplicity, but I am more than willing to add more detailed tests if necessary.

I appreciate your time and consideration in reviewing this PR and welcome any feedback you might have.

Thank you!

Description

This PR provides a guide on performing integration testing in Kotlin Multiplatform (KMP) projects using Ktor. The guide includes:

• Project structure and Gradle configuration for client-server integration tests
• Example code snippets to validate client-server interactions and improve test coverage
• Strategies to identify and resolve potential issues during simultaneous client-server development

This pull request focuses on enhancing test coverage, ensuring system stability, and reducing unexpected issues in production environments.

Changes

• Explained project structure and Gradle configuration for integration tests
• Included example tests to validate request-response flows between the client and server
• Shared best practices for increasing test coverage

Testing

• All example code snippets were verified in a local KMP project
• Integration tests confirmed the proper handling of request/response flows between the server and client
• Stability was further validated using JUnit 5-based testing, ensuring expanded test coverage

Additional Information

This guide proposes methods to go beyond unit testing by verifying system-wide interactions, thereby enhancing test coverage and building a more reliable application.

References

• Kotlin Multiplatform and Ktor: Developing Client and Server Simultaneously with Integration Testing

[vnikolova]

Thanks for your contribution @kez-lab ! 🫶
Could you please update the README.md to include a "Test" section?

[vnikolova]

@bjhham @osipxd please help to verify the code.

[bjhham]

You may want to introduce an extension function here instead. This way you can avoid the static instantiation and reuse the configuration in your test code.

Something like:

fun HttpClient.configuredForApi() = config {
    install(ContentNegotiation) {
        json(Json {
            encodeDefaults = true
            isLenient = true
            coerceInputValues = true
            ignoreUnknownKeys = true
        })
    }
    defaultRequest {
        host = "1.2.3.4"
        port = 8080
    }
}

[kez-lab]

Thank you for the suggestion! I've updated the code to use an extension function as you recommended. By introducing the configuredForApi extension function, the configuration logic is now reusable across both the main application code 😄

However, in the test code, I utilized testApplication, which does not require the use of the defaultRequest block. Therefore, I created a separate extension function specifically tailored for the test environment.

[osipxd]

Let's keep a namespace similar to the one used in composeApp module:

Suggested change

	namespace = "io.github.kez_lab.multipatform.full.integrationtest"
	namespace = "org.example.ktor.integrationtest"

[osipxd]

Modern versions of AGP add kotlin/ directory to source sets themself, so we can drop this line

[osipxd]

-jvm suffix could be dropped when we use Gradle as a build system:

Suggested change

	ktor-server-content-negotiation-jvm = { module = "io.ktor:ktor-server-content-negotiation-jvm", version.ref = "ktor" }
	ktor-server-content-negotiation= { module = "io.ktor:ktor-server-content-negotiation", version.ref = "ktor" }

[osipxd]

I think this function could both, create and configure an HttpClient, since you don't reuse this extension from tests:

Suggested change

	fun HttpClient.configuredForApi() = config {
	fun createHttpClient() = HttpClient {

In real life this method would be called in some DI framework providing a singleton HttpClient.

[osipxd]

Let's add a package to tests. You don't have to put the files into physical packages, just add a correct package directive on the top of each file.