MySQL Mocking with Speedscale's proxymock: A Complete Guide

Introduction

Testing database-driven applications is notoriously painful.

If your app depends on MySQL, you’ve probably spent hours setting up local databases, running migrations, loading data, and then cleaning everything up just to rerun your tests. This repetitive cycle slows development, breaks pipelines, and introduces inconsistency between local and production environments.

Matt explains this perfectly in this video: when your testing process depends on a live database, you’re constantly fighting setup issues rather than building features. Every developer wants accurate tests, but not at the cost of productivity.

This is where Speedscale’s proxymock comes in. proxymock allows you to record and mock MySQL traffic, enabling your application to behave as if it’s connected to a real database without requiring one to be running. This blog will guide you through what MySQL mocking is, its benefits, and how to implement it step-by-step using proxymock.

What is MySQL and Why Mock It?

MySQL is one of the world’s most popular open-source relational database management systems (RDBMS). It powers countless applications, from small web apps to enterprise-grade systems.

But when it comes to local development and CI/CD testing, running a full MySQL instance can be unnecessary or inefficient. Mocking solves this problem by allowing you to:

• Simulate database responses without an actual running database.
• Reproduce production scenarios consistently for debugging.
• Speed up local testing by removing database setup time.
• Run CI pipelines faster without containerized or external MySQL dependencies.
• Avoid waiting for data refreshes or shared environment resets.
• Work with your own isolated database instance without stepping on other developers’ data.

proxymock makes this easy by recording real MySQL traffic and then replaying it in subsequent tests.

Typical Solution

The traditional approach is to replicate production as closely as possible. You make a copy of your database, clean the data, spin up MySQL locally, and load the copy into it. Then you point your application at this database and start testing.

That works… until you realize you have to do it again every time your schema or data changes. Each test run becomes a mini DevOps project.

It looks something like this:

This approach is functional but inefficient. Resetting the database, reloading data, or reproducing complex transactions across multiple tables takes time. On large teams, that delay compounds fast.

Every engineer ends up babysitting their test data instead of building or debugging code.

Our Solution: Service Mocking

At Speedscale, we built proxymock to make service mocking effortless.

Instead of running a real database, you can record and replay actual MySQL interactions. proxymock captures the communication between your app and a live MySQL service once, then simulates that same behavior later — just like the real thing, but faster and isolated.

The mock supplies recorded responses without implementing a general database or its mutable state.

Key benefits include:

• Realistic behavior: all queries and responses match real-world traffic.
• Repeatable results: your tests are consistent across runs and machines.
• Instant startup: no waiting for MySQL to boot or data to load.
• Simplicity: setup takes minutes, not hours.

How It Works

Here’s what the workflow looks like in practice.

Recording MySQL Traffic with proxymock

When debugging or testing database-dependent services, being able to replay real MySQL interactions can save hours of setup and guesswork. proxymock makes this possible by recording live database traffic into Request/Response Pair (RRPair) files.

Start the Recorder

In a dedicated terminal, run:

proxymock record --map 13306=localhost:3306 --app-port 8080

This command tells proxymock to:

• Listen on port 13306
• Forward all traffic to the real MySQL server at 3306
• Capture each request and response as an RRPair

You can learn more about how this works in the proxymock docs.

Configure Your MySQL Connection

In a separate terminal, configure your application to route traffic through the proxy:

export MYSQL_HOST=localhost
export MYSQL_PORT=13306
export MYSQL_DATABASE=auth_db
java -jar target/auth-1.1.7.jar

Normally, apps connect directly to localhost:3306.

By switching to 13306, you route all database queries through proxymock, enabling it to record them.

If you’re using the demo app, make sure MySQL is running and the demo database exists (see the demo README).

Start proxymock with the MySQL mapping from 13306 to localhost:3306 and app port 8080. Run the Java auth app with MYSQL_PORT=13306 and the actual test database configuration, exercise the auth workflow, and save the real recording path.

What Gets Recorded

After interacting with your app, browse the captured data in a local web UI:

proxymock web --in .

You’ll see every SQL statement your app sent, from the connection handshake and session setup queries to your own SELECTs.

Each RRPair file includes:

• Request data: SQL queries, prepared statements, and connection handshakes
• Response data: Result sets, errors, and metadata
• Timing info: Query execution times and latency

Although MySQL uses a binary protocol, proxymock converts it into readable JSON.

You can even edit these files to simulate different responses or test edge cases.

Inspect the MySQL recording in proxymock web. Verify the required inbound API calls, authentication and setup exchanges, SQL requests, and responses are present before switching to mocks.

Starting the Mock Server

Keep the application pointed at the mapped listener on port 13306. Stop the recorder before starting the mock on that same listener:

proxymock mock --in ./proxymock --map 13306=mysql://localhost:3306

The mock reads the saved exchanges under the input directory. It does not create a default listener on port 3306 merely because the command is running. Exercise the recorded path and inspect matches. A matching response tests the caller against the fixture; it does not execute the SQL in a database engine.

Serve the actual recorded MySQL traffic on port 13306 with passthrough disabled using supported options. Stop the real test database, run the Java app with the same port mapping, and verify the selected auth workflow without live database access.

Modifying Responses

You can manually edit the RRPair files (Markdown or JSON) to change returned values, inject errors, or tweak timing.

To automate transformations, use Speedscale Enterprise transforms:

proxymock cloud push snapshot

This uploads your snapshot to the Speedscale Cloud.

A link will be provided — open it in the UI to add transforms such as:

• Randomized IDs or timestamps
• Latency injection
• Error simulation

Click Save, then download the modified snapshot:

proxymock cloud pull snapshot <id>

You’ll see a new .metadata directory containing your transform definitions. Next time you run:

proxymock mock

Those transforms will automatically apply to your mock.

Use the record, inspect, and mock cycle to maintain controlled responses for the application paths you exercised.

Perfect for testing, troubleshooting, or CI/CD environments without needing a live database.

Copy the MySQL recording before changing a response. Verify supported local editing or snapshot transfer options, review sensitive data and the destination before any upload, and rerun the affected test against only the intended copy.

Value of proxymock

Database mocks can remove database provisioning from tests of application behavior. Measure that saving against the cost of recording, reviewing, and maintaining the fixtures for your own suite. Keep real-database checks for migrations, SQL behavior, transactions, and performance rather than treating a mock as a replacement for every database test.

Troubleshooting Recording Issues

If you encounter problems while recording traffic, check the following:

• Ensure your MySQL driver supports SOCKS5 proxy or use reverse proxy mapping.
• Verify that the application uses the mapped listener and that the driver’s proxy and TLS settings match the capture path.
• Make sure your MySQL server is actually accessible by proxymock.

proxymock cloud push snapshot
proxymock cloud pull snapshot <id>

Diagnose a MySQL recording issue locally first by checking mappings, configured app port, client compatibility, and captured exchanges. Verify current snapshot commands if transfer is needed and show the data scope and destination before uploading.

When to Use MySQL Mocking

MySQL mocking is especially valuable for:

• CI/CD pipelines where you want deterministic test results.
• Load testing without setting up massive amounts of test data.
• Feature development when backend teams are still building the actual database schema.
• Resilience testing to ensure your app handles database downtime gracefully.

Run this workflow with an LLM

Give this prompt to a coding assistant with access to your project and this article. Supply environment-specific values it cannot discover.

Read https://speedscale.com/blog/mysql-mocking-with-speedscales-proxymock-a-complete-guide/ and inspect my project instructions first. Record the Java auth demo's real MySQL exchanges through port 13306, then run the same application against recorded responses without the live database. Inspect query coverage, preserve the source recording, and verify any edited response in an isolated copy. Check installed tool help before adapting commands. Report the checks actually run, their results, and anything you could not verify.

Conclusion

proxymock makes it simple to replace a real MySQL database with a lightweight, simulated environment. By recording real interactions and replaying them later, you can dramatically simplify local development and testing.

With this setup, you’ll be able to:

• Record MySQL traffic once.
• Run your app in mock mode without a real database.
• Customize responses for advanced testing scenarios.

This approach not only saves time but also ensures consistency and reliability across your dev and CI environments.

Next Steps

If you’re tired of database setup slowing down your testing workflow, it’s time to give proxymock a try.

Watch Matt’s video - he walks through the core pain points and why mocking is a game-changer.

Read the MySQL Docs - for detailed instructions, architecture visuals, and advanced examples.

Download proxymock - and start mocking your MySQL traffic in minutes.

Test your MySQL 8.4 upgrade - replay the same recording against a real database to catch regressions and load test it.

Simplify your stack. Speed up your tests. Get back to building.