Does Keploy replace MockK for Kotlin testing?

No. Keploy replaces the integration layer, where stubs and MockEngine handlers are costly to maintain. Keep MockK for unit tests of individual classes — Keploy generates the API-level regression suite from real traffic alongside it.

Do I need coroutine test scaffolding with Keploy?

No. Keploy records the running process rather than driving suspend functions directly, so there is no runTest, no TestDispatcher, and no scope leakage between tests to reason about.

Is Keploy an alternative to Ktor's MockEngine?

Yes, for integration tests. MockEngine responds with a handler you write, so it cannot notice upstream drift. Keploy records the real HttpClient response at the socket layer and replays it.

Can Keploy mock Exposed and JDBC queries?

Yes. Keploy records the database wire protocol beneath the JDBC driver, so Exposed, JOOQ, and Spring Data all replay with the exact rows they received. No test schema and no migration run in CI.

Does Keploy work with Ktor and Spring Boot in Kotlin?

Yes, and identically. Capture happens at the socket rather than inside the framework, so Ktor plugins, Spring filters, and Micronaut interceptors all execute on every recorded request.

Is Keploy free for Kotlin projects?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any Kotlin service with no seat limits. It is not a Gradle dependency, so it never enters your build file.

Keploy as a Kotlin testing framework

Keploy tests Kotlin services by recording real HTTP and JDBC traffic from a running JVM process, then replaying it as assertions. There are no MockK stubs to declare, no coEvery blocks to keep in sync, and no Testcontainers Docker requirement in CI.

Generate Kotlin tests free

keploy record -c "java -jar build/libs/orders.jar"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Kotlin team

Any Kotlin JVM service, unchanged

Keploy runs the JAR Gradle builds. Ktor, Spring Boot with Kotlin, Micronaut, and Http4k all record the same way, because capture happens at the socket rather than inside the framework or the coroutine dispatcher.

Kotlin 1.8 and above on the JVM
Ktor, Spring Boot, Micronaut, Http4k
Coroutines and blocking code alike
No test source set changes

Try Keploy for free Explore the docs

The problem

Why Kotlin integration tests slow teams down

The friction is rarely the assertions. It is everything around them — spinning up dependencies, keeping mocks honest, and repairing tests after every refactor.

Book a call Explore the docs

Three ways to do it

Testing Kotlin: by hand, with JUnit 5 + MockK, or with Keploy

MockK stubs and a Ktor MockEngine are both written from your model of a dependency. Keploy records what the dependency actually returned, so a stub cannot quietly diverge from it.

By hand

JUnit 5 + MockK

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for Kotlin vs what Keploy records

All three produce the same assertion. Only the third still passes after the next refactor without anyone editing it.

By hand2–4 hours

OrderServiceTest.kt

hand-written

// Hand-written: interfaces and fakes exist only for this test.

package com.acme.orders

import kotlin.test.Test

import kotlin.test.assertEquals

import kotlinx.coroutines.test.runTest

class FakeOrderRepo : OrderRepo {

override suspend fun get(id: String) = Order(id, 4200, "NEW")

}

class FakePayments : Payments {

override suspend fun authorize(token: String) = "AUTHORIZED"

}

class OrderServiceTest {

@Test

fun `confirms an authorized order`() = runTest {

val service = OrderService(FakeOrderRepo(), FakePayments())

val result = service.confirm("ord_1", "tok_123")

assertEquals("CONFIRMED", result.state)

}

Two interfaces exist in production code purely so these fakes can be substituted, and neither fails when the real contract changes.

JUnit 5 + MockK1–2 hours

OrderServiceMockkTest.kt

tool-assisted

// JUnit 5 + MockK + Ktor MockEngine.

package com.acme.orders

import io.mockk.coEvery

import io.mockk.mockk

import kotlinx.coroutines.test.runTest

class OrderServiceMockkTest {

// Relaxed: an undeclared call returns a default instead of failing.

private val repo = mockk<OrderRepo>(relaxed = true)

private val payments = mockk<Payments>()

@Test

fun `confirms an authorized order`() = runTest {

coEvery { repo.get("ord_1") } returns Order("ord_1", 4200, "NEW")

coEvery { payments.authorize("tok_123") } returns "AUTHORIZED"

val result = OrderService(repo, payments).confirm("ord_1", "tok_123")

assertEquals("CONFIRMED", result.state)

}

Concise and coroutine-aware — and the payment contract is whatever the coEvery line claims, while the relaxed repo hides any call nobody declared.

With Keploy~5 minutes

test-1.yaml

auto-generated

# Recorded with: keploy record -c 'java -jar build/libs/orders.jar'

# No MockK stub. No MockEngine. No coroutine scaffolding.

version: api.keploy.io/v1beta1

kind: Http

name: test-1

spec:

req:

method: POST

url: /orders/ord_1/confirm

body: '{"paymentToken":"tok_123"}'

resp:

status_code: 200

body:

id: "ord_1"

state: "CONFIRMED"

amountMinor: 4200

confirmedAt: "2026-09-02T11:04:18Z"

noise:

- body.confirmedAt

mocks:

- kind: SQL

operation: "SELECT id, amount_minor, state FROM orders WHERE id = ?"

- kind: Http

url: https://api.payments.example.com/v1/payment_intents/tok_123/confirm

status: 200

Every suspend function on the path actually ran, so a call nobody thought to declare cannot silently return a relaxed default.

Times are estimates for authoring one endpoint’s coverage from scratch, not measurements.

Explore the docs Request a trial

Keploy vs the alternatives

Kotlin testing tools, compared

The options a team on the JVM actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

JUnit + Mockito

WireMock

REST Assured

Testcontainers

Postman

SmartBear ReadyAPI

Best in classStrongPartialNot covered

Assessments reflect each tool’s documented behaviour, not benchmark measurements.

Request a trial Book a call

How it works

Record your Kotlin app once, replay it forever

Keploy sits below your Kotlin process at the network layer. It watches the calls your app already makes, then serves them back on replay so tests run with no dependencies attached.

Your Kotlin appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

PostgreSQLPostgres protocol under Exposed and JDBC

MySQLMySQL protocol under Exposed and JDBC

RedisRESP under Lettuce and Jedis

MongoDBWire protocol under the Kotlin driver

+3 more Kotlin dependencies

An example shape of a captured call. Your own endpoints and dependencies come from your real traffic, so nothing here has to be written by hand.

Try Keploy for free Request a trial

Mock coverage

What Keploy mocks for Kotlin, with zero config

7 of the 7 dependencies a typical Kotlin service talks to are stubbed from the recording itself — no mock classes, no fixture files, no containers in CI.

Auto-mocked
PostgreSQLView page
Postgres protocol under Exposed and JDBC
Auto-mocked
MySQLView page
MySQL protocol under Exposed and JDBC
Auto-mocked
RedisView page
RESP under Lettuce and Jedis
Auto-mocked
MongoDBView page
Wire protocol under the Kotlin driver
Auto-mocked
Apache KafkaView page
Kafka protocol under the Java client
Auto-mocked
gRPCView page
HTTP/2 framed calls from grpc-kotlin
Outbound HTTP
Auto-mocked
Outbound HTTP
Any Ktor HttpClient or OkHttp call

Explore the docs Book a call

Quick start

Your first Kotlin test suite in under five minutes

Every command below runs against your existing Kotlin service. Nothing in your source tree changes.

1
1Install the Keploy CLI
A single binary. It needs a Linux kernel with eBPF support, or Docker on macOS and Windows — and it adds nothing to your project's dependencies.
curl -sSL https://keploy.io/install.sh | bash
2
2Record your service
Pass the command you already use to start the app. Keploy runs it and watches every socket it opens.
keploy record -c "java -jar build/libs/orders.jar"
3
3Exercise the paths you care about
Build as normal, then drive the JAR. Every request becomes a test case with its JDBC and HTTP client calls captured alongside.
./gradlew build
curl -X POST localhost:8080/orders/ord_1/confirm -H 'Content-Type: application/json' -d '{"paymentToken":"tok_123"}'
4
4Replay in CI
Replay serves the recorded dependency responses, so the job needs no service containers and no Docker daemon.
keploy test -c "java -jar build/libs/orders.jar" --delay 15