Does Keploy replace cargo test for Rust?

No. Keploy replaces the integration layer, where traits and wiremock servers are costly to maintain. Keep cargo test and mockall for unit tests of individual functions — Keploy generates the API-level regression suite from real traffic and runs alongside them.

Do I need traits to use Keploy with Rust?

No. Keploy captures traffic outside your process at the socket layer, so it never substitutes a collaborator inside the binary. Handlers keep concrete types and you can delete any trait that exists only so a mockall double could be swapped in.

Is Keploy a wiremock alternative for Rust?

Yes, for integration tests. wiremock serves responses you register in test code, so it cannot notice upstream drift. Keploy records the real reqwest response at the socket layer and replays it, so re-recording refreshes every mock at once.

Can Keploy mock sqlx queries?

Yes. Keploy records the Postgres or MySQL wire protocol beneath sqlx, so a query replays with the exact rows it received. There is no test database to create, no migration run, and no sqlx::test attribute needed.

Does Keploy work with Axum and Actix Web?

Yes, and identically. Because capture happens at the network layer rather than inside the router, the framework, extractor set, and middleware chain make no difference to what Keploy records or replays.

Is Keploy free for Rust projects?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any Rust service with no seat limits. It is not a crate, so it never appears in Cargo.toml or affects your dependency resolution.

Keploy as a Rust testing framework

Keploy tests Rust services by recording real HTTP and database traffic from a running binary, then replaying it as assertions. There are no traits to extract for mockall, no wiremock server to stand up per upstream, and no sqlx test database to migrate.

Generate Rust tests free

keploy record -c "./target/release/orders"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Rust team

Any Rust binary, unchanged

Keploy runs the binary cargo builds. Axum, Actix Web, Rocket, and warp all record the same way, because interception happens at the socket rather than inside the router or the async runtime.

Stable Rust, any edition
Tokio and async-std both fine
No cfg(test) entrypoint
HTTP and gRPC servers supported

Try Keploy for free Explore the docs

The problem

Why Rust 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 Rust: by hand, with mockall + wiremock, or with Keploy

mockall needs a trait to generate from and wiremock needs a handler you write. Keploy captures outside the process, so production signatures stay clean and no upstream contract is written down twice.

By hand

mockall + wiremock

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

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

orders_manual_test.rs

hand-written

// Hand-written: a trait and a fake exist only for this test.

use axum::http::StatusCode;

struct FakeOrderRepo;

#[async_trait]

impl OrderRepo for FakeOrderRepo {

async fn get(&self, id: &str) -> Result<Order> {

Ok(Order { id: id.into(), amount_minor: 4200, state: "NEW".into() })

}

struct FakePayments;

#[async_trait]

impl Payments for FakePayments {

async fn authorize(&self, _tok: &str) -> Result<String> {

Ok("AUTHORIZED".into())

}

#[tokio::test]

async fn confirms_an_authorized_order() {

let app = build_app(FakeOrderRepo, FakePayments);

let res = post(&app, "/orders/ord_1/confirm").await;

assert_eq!(res.status(), StatusCode::OK);

}

Two traits exist in production code purely so these two fakes can be substituted. Neither fake fails when the real contract changes.

mockall + wiremock1–2 hours

orders_mockall_test.rs

tool-assisted

// mockall + wiremock: doubles and a real HTTP server.

use mockall::predicate::*;

use wiremock::{Mock, MockServer, ResponseTemplate};

use wiremock::matchers::{method, path};

#[tokio::test]

async fn confirms_an_authorized_order() {

let upstream = MockServer::start().await;

// A template that will not change when Stripe does.

Mock::given(method("POST"))

.and(path("/v1/payment_intents/tok_123/confirm"))

.respond_with(ResponseTemplate::new(200)

.set_body_json(serde_json::json!({ "status": "AUTHORIZED" })))

.mount(&upstream)

.await;

let mut repo = MockOrderRepo::new();

repo.expect_get()

.with(eq("ord_1"))

.returning(|id| Ok(Order::new(id, 4200, "NEW")));

let app = build_app(repo, Payments::new(upstream.uri()));

let res = post(&app, "/orders/ord_1/confirm").await;

assert_eq!(res.status(), 200);

}

Compile-time-checked and fast — and the Stripe body is still a literal in test code, and MockOrderRepo still needs a trait in production to generate from.

With Keploy~5 minutes

test-1.yaml

auto-generated

# Recorded with: keploy record -c './target/release/orders'

# No trait, no mockall double, no wiremock server.

version: api.keploy.io/v1beta1

kind: Http

name: test-1

spec:

req:

method: POST

url: /orders/ord_1/confirm

body: '{"payment_token":"tok_123"}'

resp:

status_code: 200

body:

id: "ord_1"

state: "CONFIRMED"

amount_minor: 4200

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

noise:

- body.confirmed_at

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

status: 200

The SQL and the upstream response are recorded, not restated — and the handler's signature keeps its concrete types because nothing had to become a trait.

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

Explore the docs Request a trial

Keploy vs the alternatives

Rust testing tools, compared

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

Keploy

cargo test + mockall

wiremock-rs

httpmock

sqlx::test

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

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

RecordingKeploy proxyeBPF · userspace

PostgreSQLPostgres protocol under sqlx and tokio-postgres

MySQLMySQL protocol under sqlx

RedisRESP under redis-rs

MongoDBWire protocol under the mongodb crate

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

7 of the 7 dependencies a typical Rust 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 sqlx and tokio-postgres
Auto-mocked
MySQLView page
MySQL protocol under sqlx
Auto-mocked
RedisView page
RESP under redis-rs
Auto-mocked
MongoDBView page
Wire protocol under the mongodb crate
Auto-mocked
Apache KafkaView page
Kafka protocol under rdkafka
Auto-mocked
gRPCView page
HTTP/2 framed calls from tonic
Outbound HTTP
Auto-mocked
Outbound HTTP
Any reqwest or hyper client call

Explore the docs Book a call

Quick start

Your first Rust test suite in under five minutes

Every command below runs against your existing Rust 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 "./target/release/orders"
3
3Exercise the paths you care about
Build as normal, then drive the binary. Every request becomes a test case with its sqlx and reqwest calls captured alongside.
cargo build --release
curl -X POST localhost:8080/orders/ord_1/confirm -H 'Content-Type: application/json' -d '{"payment_token":"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 "./target/release/orders" --delay 8