How do I mock SQL Server queries in tests?

Record your application once against a real SQL Server with Keploy. It captures each query, its parameters, and the result set the server returned at the TDS layer, then answers the same queries from that recording with no database running.

Can I use Keploy instead of the EF Core in-memory provider?

Yes, and with far higher fidelity. Microsoft documents the in-memory provider as unsuitable for relational testing because it does not translate SQL. Keploy replays what SQL Server itself returned, so translation is genuinely exercised.

Does Keploy capture decimal precision and scale correctly?

Yes. Column metadata including precision and scale is recorded alongside the data, so decimal and money handling is exercised on replay rather than assumed from a stub's own language types.

Does Keploy work with stored procedures?

Yes. Stored procedure execution, parameters, and result sets are all part of the TDS exchange Keploy records, so a sproc replays with the same result sets and output parameters it originally returned.

What happens if my code runs a query that was never recorded?

Replay has no response for it and the test surfaces the gap rather than inventing data. That is deliberate — a silent default would hide a code path nobody has exercised. Re-record to capture it.

Keploy as a SQL Server testing framework

Keploy mocks SQL Server by recording the TDS protocol beneath your driver, capturing the exact result sets your queries returned, then replaying them during tests. No SQL Server instance runs in CI, no schema is deployed, and no in-memory provider stands in for it.

Generate SQL Server tests free

keploy record -c "dotnet Orders.dll"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a SQL Server team

Captured at the TDS protocol

Keploy reads Tabular Data Stream beneath your driver, so the result sets that replay are the bytes SQL Server actually sent — column metadata, precision, and scale included.

Below Microsoft.Data.SqlClient and JDBC
Column metadata from the server itself
Parameterised queries and sprocs
Transactions replay in order

Try Keploy for free Explore the docs

The problem

Why SQL Server 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 SQL Server: by hand, with Testcontainers SQL Server, or with Keploy

Testcontainers gives real T-SQL semantics and charges a large image pull and a server boot per job. Keploy records that server once and replays its responses with neither.

By hand

Testcontainers SQL Server

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

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

OrderRepositoryStub.cs

hand-written

// Hand-written stub: no T-SQL is executed or validated.

public sealed class OrderRepositoryStub : IOrderRepository

{

private readonly Dictionary<string, Order> _rows = new()

{

// A guess: real decimal precision may differ.

["ord_1"] = new Order("ord_1", 42.00m, "NEW"),

};

public Task<Order?> GetAsync(string id) =>

Task.FromResult(_rows.GetValueOrDefault(id));

public Task SetStateAsync(string id, string state)

{

// No constraint, trigger, or identity behaviour is checked here.

_rows[id] = _rows[id] with { State = state };

return Task.CompletedTask;

}

The stub decides its own types and enforces nothing, so a precision mismatch or a violated constraint is impossible to reproduce.

Testcontainers SQL Server1–2 hours

OrderRepositoryTests.cs

tool-assisted

// Testcontainers SQL Server: real server, Docker in CI.

using Testcontainers.MsSql;

using Xunit;

public class OrderRepositoryTests : IAsyncLifetime

{

private readonly MsSqlContainer _sql = new MsSqlBuilder().Build();

public async Task InitializeAsync()

{

await _sql.StartAsync();

await DeploySchemaAsync(_sql.GetConnectionString());

await SeedOrdersAsync(_sql.GetConnectionString());

}

public Task DisposeAsync() => _sql.DisposeAsync().AsTask();

[Fact]

public async Task ReadsASeededOrder()

{

var repo = new SqlOrderRepository(_sql.GetConnectionString());

var order = await repo.GetAsync("ord_1");

Assert.Equal(42.00m, order!.Amount);

}

Accurate down to decimal precision — and every job pulls a multi-gigabyte image, boots a server, and deploys the schema first.

With Keploy~5 minutes

mocks.yaml

auto-generated

# Recorded with: keploy record -c 'dotnet Orders.dll'

# The SQL Server response, captured at the TDS layer.

version: api.keploy.io/v1beta1

kind: SQL

name: mock-3

spec:

request:

query: "SELECT Id, Amount, State FROM Orders WHERE Id = @id"

params:

- name: "@id"

value: "ord_1"

response:

# Column metadata, exactly as the server described it.

columns:

- name: Id

type: NVARCHAR

- name: Amount

type: DECIMAL

precision: 10

scale: 2

- name: State

type: NVARCHAR

rows:

- Id: "ord_1"

Amount: "42.00"

State: "NEW"

rows_affected: 0

Precision and scale come from SQL Server's own column metadata, so decimal handling is exercised on replay rather than assumed.

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

Explore the docs Request a trial

Keploy vs the alternatives

SQL Server testing tools, compared

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

Keploy

Testcontainers

H2

DBUnit

pg-mem

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

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

RecordingKeploy proxyeBPF · userspace

.NETMicrosoft.Data.SqlClient, EF Core, and Dapper

JavaThe Microsoft JDBC driver and Spring Data JPA

Node.jsthe mssql package and Prisma

Pythonpyodbc and SQLAlchemy

+2 more SQL Server clients

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

SQL Server clients Keploy records, driver by driver

Keploy captures SQL Server at the wire protocol, so 4 of these 6 clients need no adapter, no test double, and no SQL Server instance in CI.

Explore the docs Book a call

Quick start

Your first SQL Server test suite in under five minutes

Every command below runs against your existing SQL Server 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 "dotnet Orders.dll"
3
3Exercise the paths you care about
Run the app with your development SQL Server reachable. Every query it issues and every result set the server returns is captured together.
curl localhost:5000/orders/ord_1
curl -X POST localhost:5000/orders/ord_1/confirm -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 "dotnet Orders.dll" --delay 12