Does Keploy replace ScalaTest?

No. Keploy replaces the integration layer, where effect-stack scaffolding and container fixtures are costly. Keep ScalaTest for unit specs of individual functions — Keploy generates the API-level regression suite from real traffic alongside it.

Do I need a ZIO layer or cake pattern for Keploy?

No. Keploy captures outside the process, so nothing inside the service is substituted. Dependencies can be wired however your architecture prefers rather than however the test suite needs.

Can Keploy mock Doobie and Slick queries?

Yes. Keploy records the database wire protocol beneath the JDBC driver, so both replay with the exact rows they received. There is no test schema, no migration run, and no container in CI.

Does Keploy work with Play and Akka HTTP?

Yes, and identically. Capture happens at the socket rather than inside the routing DSL, so Play filters and Akka HTTP directives all execute on every recorded request.

Is Keploy free for Scala projects?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any Scala service with no seat limits. It is not an sbt dependency, so it never enters build.sbt.

Keploy as a Scala testing framework

Keploy tests Scala services by recording real HTTP and JDBC traffic from a running JVM process, then replaying it as assertions. There is no cake pattern or ZIO layer to restructure for testability, and no Testcontainers fixture to boot per suite.

Generate Scala tests free

keploy record -c "java -jar target/scala-3.3/orders.jar"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Scala team

Any Scala JVM service, unchanged

Keploy runs the assembled JAR. Play, Akka HTTP, http4s, and ZIO HTTP all record the same way because capture is at the socket rather than inside the effect system.

Scala 2.13 and 3.x on the JVM
Play, Akka HTTP, http4s, ZIO HTTP
Futures, cats-effect, and ZIO alike
sbt or Mill, no plugin needed

Try Keploy for free Explore the docs

The problem

Why Scala 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 Scala: by hand, with ScalaTest + Testcontainers, or with Keploy

ScalaTest describes the exchange and Testcontainers supplies a real database at a container per suite. Keploy records both halves once and replays them with nothing running.

By hand

ScalaTest + Testcontainers

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for Scala 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

OrderServiceSpec.scala

hand-written

// Hand-written: traits exist so these stubs can be substituted.

package com.acme.orders

class StubOrderRepo extends OrderRepo:

def get(id: String): IO[Order] =

IO.pure(Order(id, 4200, "NEW"))

class StubPayments extends Payments:

def authorize(token: String): IO[String] = IO.pure("AUTHORIZED")

class OrderServiceSpec extends AsyncFlatSpec:

"confirm" should "return CONFIRMED" in:

val service = OrderService(StubOrderRepo(), StubPayments())

service.confirm("ord_1", "tok_123").map: result =>

assert(result.state == "CONFIRMED")

Two traits exist in production code purely so these stubs can be injected, and neither stub fails when the real Stripe or Postgres contract changes.

ScalaTest + Testcontainers1–2 hours

OrderRepoSpec.scala

tool-assisted

// ScalaTest + Testcontainers: a real Postgres per suite.

package com.acme.orders

class OrderRepoSpec extends AsyncFlatSpec with ForAllTestContainer:

override val container: PostgreSQLContainer =

PostgreSQLContainer("postgres:16")

"get" should "return a seeded order" in:

runMigrations(container.jdbcUrl)

seedOrders(container.jdbcUrl)

DoobieOrderRepo(transactor(container))

.get("ord_1")

.map: order =>

assert(order.amountMinor == 4200)

Real query semantics — and every job pulls a Postgres image, boots it, and replays the migration history before the first assertion.

With Keploy~5 minutes

test-1.yaml

auto-generated

# Recorded with: keploy record -c 'java -jar target/scala-3.3/orders.jar'

# Nobody wrote this file. Keploy captured it from a real request.

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

noise:

- body.confirmedAt

mocks:

- kind: Postgres

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

- kind: Http

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

The SQL Doobie emitted and the upstream response are both recorded, so no trait had to exist for substitution and the effect stack ran as written.

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

Explore the docs Request a trial

Keploy vs the alternatives

Scala 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 Scala app once, replay it forever

Keploy sits below your Scala 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 Scala appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

PostgreSQLPostgres frontend/backend protocol

MySQLMySQL wire protocol

MongoDBMongoDB wire protocol

RedisRESP over TCP

+3 more Scala 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 Scala, with zero config

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

Auto-mocked
PostgreSQLView page
Postgres frontend/backend protocol
Auto-mocked
MySQLView page
MySQL wire protocol
Auto-mocked
MongoDBView page
MongoDB wire protocol
Auto-mocked
RedisView page
RESP over TCP
Auto-mocked
Apache KafkaView page
Kafka producer and consumer protocol
Auto-mocked
gRPCView page
HTTP/2 framed gRPC calls
Outbound HTTP
Auto-mocked
Outbound HTTP
Any HTTP client call the service makes

Explore the docs Book a call

Quick start

Your first Scala test suite in under five minutes

Every command below runs against your existing Scala 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 target/scala-3.3/orders.jar"
3
3Exercise the paths you care about
Assemble as normal, then drive the JAR. Every request becomes a test case with its JDBC and HTTP calls captured alongside.
sbt assembly
curl -X POST localhost:9000/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 target/scala-3.3/orders.jar" --delay 18