How do I test Gin handlers without httptest?

Record the running binary with Keploy. Because capture happens at the socket, the engine from main serves the request — so route registration, auth middleware, and binding validation are all genuinely exercised.

Is Keploy an alternative to httptest for Gin?

For integration tests, yes. httptest serves into an engine the test file assembles, so middleware configured in main is missing. Keploy records the real process, so the router under test is the one you deploy.

Can Keploy replace go-sqlmock in Gin projects?

Yes, for integration tests. sqlmock asserts on the SQL string your code emits, so every query is written twice. Keploy records the protocol beneath database/sql and captures the real rows without restating a query.

Does Gin middleware run under Keploy?

Yes. The request arrives over a real socket, so recovery, logging, CORS, and auth middleware all execute in the order main registers them, and the recorded case replays that same path.

Does Keploy work with Echo and Fiber too?

Yes, and identically. Capture happens at the network layer rather than inside the router, so Gin, Echo, Fiber, chi, and net/http all record and replay the same way.

Is Keploy free for Gin projects?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any Go service with no seat limits. It is not a Go module, so it never appears in go.mod.

Keploy as a Gin testing framework

Keploy tests Gin applications by recording real requests through the running server and every SQL or outbound call they trigger, then replaying both as assertions. There are no httptest recorders to build, no sqlmock expectations to restate, and no stub servers to maintain.

Generate Gin tests free

keploy record -c "./orders-api"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Gin team

Any Gin app, unchanged

Keploy runs the binary you build. Route groups, custom middleware, and binding validation all execute because capture happens at the socket rather than inside the Gin engine.

Gin 1.9 and above
Route groups and nested middleware
Binding and validation run for real
No test-only engine setup

Try Keploy for free Explore the docs

The problem

Why Gin 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 Gin: by hand, with testify + httptest, or with Keploy

httptest serves into an engine the test file builds, so middleware from main is missing. Keploy records the running binary, so the router under test is the one you deploy.

By hand

testify + httptest

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

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

handler_manual_test.go

hand-written

// Hand-written: an engine built in the test, not in main.

package api

import (

"net/http/httptest"

"strings"

"testing"

"github.com/gin-gonic/gin"

)

func TestConfirmOrder(t *testing.T) {

r := gin.New()

// Note what is missing: the auth and recovery middleware main adds.

r.POST("/orders/:id/confirm", NewHandler(fakeRepo{}, fakePayments{}).Confirm)

body := strings.NewReader(`{"paymentToken":"tok_123"}`)

req := httptest.NewRequest("POST", "/orders/ord_1/confirm", body)

rec := httptest.NewRecorder()

r.ServeHTTP(rec, req)

if rec.Code != 200 {

t.Fatalf("got %d, want 200", rec.Code)

}

The engine is assembled here, not in main, so auth and recovery middleware are absent and an unauthorised route would still pass.

testify + httptest1–2 hours

handler_sqlmock_test.go

tool-assisted

// testify + sqlmock + httptest stub upstream.

package api

import (

"testing"

"github.com/DATA-DOG/go-sqlmock"

"github.com/stretchr/testify/assert"

)

func TestConfirmOrder(t *testing.T) {

db, mock, _ := sqlmock.New()

defer db.Close()

// The query now lives in two places.

mock.ExpectQuery("SELECT id, amount_minor, state FROM orders").

WithArgs("ord_1").

WillReturnRows(sqlmock.NewRows([]string{"id", "amount_minor", "state"}).

AddRow("ord_1", 4200, "NEW"))

upstream := httptest.NewServer(stripeStub())

defer upstream.Close()

rec := serve(t, NewRepo(db), NewPayments(upstream.URL))

assert.Equal(t, 200, rec.Code)

assert.NoError(t, mock.ExpectationsWereMet())

}

Fast and idiomatic — and the SQL string is duplicated while stripeStub() is a handler someone has to keep current by hand.

With Keploy~5 minutes

test-1.yaml

auto-generated

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

# The real engine from main. All middleware ran.

version: api.keploy.io/v1beta1

kind: Http

name: test-1

spec:

req:

method: POST

url: /orders/ord_1/confirm

header:

Authorization: Bearer <captured>

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

resp:

status_code: 200

header:

X-Request-Id: "<captured>"

body:

id: "ord_1"

state: "CONFIRMED"

amountMinor: 4200

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

noise:

- body.confirmedAt

- header.X-Request-Id

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 request-id header is evidence the real middleware chain from main ran — something a test-assembled engine never shows.

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

Explore the docs Request a trial

Keploy vs the alternatives

Gin testing tools, compared

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

Keploy

testify + httptest

go-sqlmock

GoMock

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

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

RecordingKeploy proxyeBPF · userspace

PostgreSQLPostgres protocol under pgx and lib/pq

MySQLMySQL protocol under go-sql-driver

RedisRESP under go-redis

MongoDBWire protocol under mongo-driver

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

7 of the 7 dependencies a typical Gin 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 pgx and lib/pq
Auto-mocked
MySQLView page
MySQL protocol under go-sql-driver
Auto-mocked
RedisView page
RESP under go-redis
Auto-mocked
MongoDBView page
Wire protocol under mongo-driver
Auto-mocked
Apache KafkaView page
Kafka protocol under sarama and kafka-go
Auto-mocked
gRPCView page
HTTP/2 framed calls from google.golang.org/grpc
Outbound HTTP
Auto-mocked
Outbound HTTP
Any net/http or resty client call

Explore the docs Book a call

Quick start

Your first Gin test suite in under five minutes

Every command below runs against your existing Gin 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 "./orders-api"
3
3Exercise the paths you care about
Build as normal, then drive the binary. Every request becomes a test case with its SQL and HTTP calls captured alongside.
go build -o orders-api ./cmd/api
curl -X POST localhost:8080/orders/ord_1/confirm -H 'Content-Type: application/json' -H 'Authorization: Bearer $TOKEN' -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 "./orders-api" --delay 6