Does Keploy replace JUnit for Java testing?

No. Keploy replaces the integration and API test layer, where tests are expensive to write and to keep honest. Keep JUnit and Mockito for unit tests of individual classes — Keploy generates the service-level regression suite around them from real traffic.

Do I need to add a dependency to my pom.xml?

No. Keploy runs outside the JVM and captures traffic at the network layer, so there is nothing to add to Maven or Gradle, no agent to attach, and no annotation to apply. Your build file and source tree are untouched.

Can Keploy mock JDBC calls to MySQL and PostgreSQL?

Yes. Keploy records the database wire protocol beneath your JDBC driver, so the exact result sets your queries returned are replayed back on test runs. No test schema, no seed data, and no database container in CI.

Is Keploy a Testcontainers alternative for Java?

For integration tests, largely yes. Testcontainers boots real dependencies and needs a Docker daemon in every runner; Keploy records those dependencies once and replays them with no daemon. Testcontainers remains the better fit when you must exercise real database behaviour.

How does Keploy handle timestamps and generated IDs?

Keploy compares repeated recordings, flags fields that change between them as noise, and excludes those from assertions. Timestamps, UUIDs, and request IDs stop causing false failures without anyone writing a custom matcher or freezing a Clock bean.

Is Keploy free for Java projects?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any Java service, self-hosted with no seat limits. Paid cloud plans add hosted test storage, dashboards, and team management on top.

Keploy as a Java testing framework

Keploy tests Java applications by recording real HTTP and JDBC traffic at the network layer, then replaying it as assertions. You add no annotations, no test dependencies, and no Docker containers — Keploy runs your existing JAR and turns observed behaviour into a regression suite.

Generate Java tests free

keploy record -c "java -jar orders.jar"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Java team

Any JVM service, unchanged

Keploy runs the JAR you already deploy. Spring Boot, Quarkus, Micronaut, Dropwizard, and plain servlet apps all record the same way, because capture happens at the socket rather than inside the framework.

JVM 8 and above, any build tool
No annotations and no test-scoped dependencies
Works with an embedded server or a WAR on Tomcat
Reactive and blocking endpoints record identically

Try Keploy for free Explore the docs

The problem

Why Java 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 Java: by hand, with JUnit + Mockito, or with Keploy

JUnit and Mockito describe behaviour you already understand. Keploy derives it from traffic your service already served — so coverage grows without anyone writing a test class.

By hand

JUnit + Mockito

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

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

OrderControllerTest.java

hand-written

// Hand-written: fixtures, fakes, and assertions all by hand.

package com.acme.orders;

import org.junit.jupiter.api.*;

import static org.junit.jupiter.api.Assertions.*;

class OrderControllerTest {

private FakeOrderRepository repo;

private FakePaymentClient payments;

private OrderController controller;

@BeforeEach

void setUp() {

repo = new FakeOrderRepository();

payments = new FakePaymentClient();

payments.stub("tok_123", "AUTHORIZED");

repo.seed(new Order("ord_1", 4200, "NEW"));

controller = new OrderController(repo, payments);

}

@Test

void confirmsAnAuthorizedOrder() {

var response = controller.confirm("ord_1", "tok_123");

assertEquals(200, response.status());

assertEquals("CONFIRMED", response.body().state());

assertNotNull(response.body().confirmedAt());

}

Two fake classes exist only to serve this test. Both encode a guess about the real dependency, and neither fails when that guess goes stale.

JUnit + Mockito1–2 hours

OrderControllerIT.java

tool-assisted

// JUnit 5 + Mockito + Testcontainers.

package com.acme.orders;

import org.junit.jupiter.api.*;

import org.mockito.Mock;

import org.testcontainers.containers.MySQLContainer;

import static org.mockito.Mockito.*;

class OrderControllerIT {

static MySQLContainer<?> mysql = new MySQLContainer<>("mysql:8.0");

@Mock PaymentClient payments;

@BeforeAll

static void boot() { mysql.start(); }

@AfterAll

static void stop() { mysql.stop(); }

@Test

void confirmsAnAuthorizedOrder() {

when(payments.authorize("tok_123")).thenReturn("AUTHORIZED");

var response = controller.confirm("ord_1", "tok_123");

assertEquals("CONFIRMED", response.body().state());

verify(payments).authorize("tok_123");

}

Correct and idiomatic — but the runner now needs a Docker daemon, and the payment stub is still a hand-written assumption about the upstream contract.

With Keploy~5 minutes

test-1.yaml

auto-generated

# Recorded with: keploy record -c 'java -jar 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

header:

Content-Type: application/json

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

resp:

status_code: 200

body:

id: "ord_1"

state: "CONFIRMED"

amountMinor: 4200

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

# Fields that change every run — excluded from assertions.

noise:

- body.confirmedAt

- header.X-Request-Id

# The JDBC and HTTP calls this request made, mocked on replay.

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

The mocks block is the real payment response and the real JDBC result set. When either contract changes, the recording changes with it.

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

Explore the docs Request a trial

Keploy vs the alternatives

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

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

RecordingKeploy proxyeBPF · userspace

MySQLMySQL wire protocol via JDBC

PostgreSQLPostgreSQL frontend/backend protocol

MongoDBMongoDB wire protocol

RedisRESP over TCP

+4 more Java 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 Java, with zero config

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

Auto-mocked
MySQLView page
MySQL wire protocol via JDBC
Auto-mocked
PostgreSQLView page
PostgreSQL frontend/backend 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 RestTemplate, WebClient, or OkHttp call
Partial
Amazon S3
S3 REST API over HTTPS

Explore the docs Book a call

Quick start

Your first Java test suite in under five minutes

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

1
1Install the Keploy CLI
One binary. It needs a Linux kernel with eBPF support, or Docker on macOS and Windows.
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 the sockets.
keploy record -c "java -jar target/orders-1.0.0.jar"
3
3Exercise the endpoints you care about
Use curl, Postman, your frontend, or a smoke script. Every request becomes a test case with its dependency calls attached.
curl -X POST localhost:8080/orders/ord_1/confirm -H 'Content-Type: application/json' -d '{"paymentToken":"tok_123"}'
4
4Replay the suite in CI
Replay needs no database and no broker, so it drops into any runner as a single step.
keploy test -c "java -jar target/orders-1.0.0.jar" --delay 10