A test that checks whether a delayed shipment triggers a warning can use a function returning delayed. A test of the carrier API client needs more: the real client must send a request and parse a response. Both tests can use a stand-in, but they exercise different parts of your application.
Service virtualization and network mocking overlap. Both can simulate a dependency at the network boundary. A virtual service may include state transitions, timing or several endpoints, depending on what you configure. Moving to a tool called service virtualization doesn’t automatically make a test more realistic.
For captured API interactions, Speedscale’s proxymock supplies local dependency mocks and traffic replay. Speedscale Cloud supports dependency mocking during Kubernetes replays. Choose the boundary your test needs before choosing the product.
Choose by the behavior you need to test
The terms are easier to use when you start with a specific test question:
| Test question | Start with | What stays real |
|---|---|---|
| Does a delayed shipment produce the warning? | A function stub returning delayed | The decision logic |
| Was the notification sent once, with the right arguments? | A spy or expectation-based mock | The caller and its workflow |
| Does a second notification attempt recognize an earlier one? | A stateful fake | The code that reads and updates the fake |
| Does the client build the right request and handle the response? | A network mock or virtual service | The client, serialization and error handling |
In Martin Fowler’s test-double vocabulary, a stub supplies prepared answers, a spy records calls, and a mock includes expectations about interactions. A fake has a working implementation with shortcuts that suit testing. Product documentation often uses “mock” more broadly, including for HTTP servers that return matching fixtures.
Our Getting Started with Mocks series follows the shipment example through these choices. They Aren’t All Mocks shows the differences in Java, Node.js, Go and Python. Use those examples when a function-level double is enough; the proxymock capstone moves the test to the network boundary.
State comes from the behavior you implement
In the linked mocking series, the notification example uses an in-memory recorder to remember which tracking numbers have already been handled. That fake can answer a later read using an earlier write. A list of canned responses has no such behavior unless you add it.
Network tools can model selected state transitions too. WireMock scenarios use a state machine to select responses and move between states. Hoverfly stores state values that matchers can require or change. Statefulness is a capability to configure, not a dividing line between mocking and service virtualization.
For a multi-user test, check whether one user’s request changes another user’s result. Reset scenario state between runs when each test expects a fresh environment. Keep a real dependency test for that dependency’s validation and persistence rules.
Recording reduces the fixture work
You don’t have to author every request and response by hand. WireMock’s recorder can generate stub mappings from proxied API interactions. proxymock records request/response pairs that can serve as outbound dependency mocks and inbound replay inputs.
The existing capstone uses the mock-lab application, which exposes an HTTP API and calls a projects API downstream. It shows how to record the exchanges, mock the downstream responses and replay requests through the real application. It also covers injected failures and simulated contract changes.
Review the captured cases and matching rules before treating the recording as a test fixture. Fresh traffic or a live contract check is how you discover that a provider changed. Configure and verify DLP rules before sharing captured traffic; a recording may contain credentials or personal data.
Run mocks where the application needs them
A network mock can run beside a developer’s app or in an isolated test environment. It does not have to be a centralized server. WireMock provides an official Docker image, and proxymock runs on your machine. The client still needs to reach the intended mock through the routing or proxy configuration supported by that setup.
Use proxymock for a local application or CLI-driven CI workflow. Start with the installation and activation instructions. Non-interactive CI requires proxymock Pro or Speedscale Enterprise; free local activation does not grant CI access.
Use Speedscale Cloud when your application runs in Kubernetes and you need cluster capture and replay. Its backend-mocking controls let you select which recorded dependencies to mock during a replay. You can retain a real test instance for a dependency whose behavior you need to exercise.
Compare the protocols, state behavior and deployment model of the specific tool you plan to use. Check its current license for the way your team will run it. A mocking or virtualization label doesn’t determine those choices.
The mock supplies responses; the test must check the application
The CI tutorial’s local proof uses the mock-lab Go app with recorded downstream responses. Changing GET /api/stats to return 25 projects instead of 24 still produces HTTP 200. The replay gate exits 3 because the candidate introduces a body mismatch against the reviewed baseline. Restoring the handler returns the gate to exit 0.
That proof comes from a local run of eight synthetic demo requests. The tutorial’s GitHub Actions workflow is a configuration example. It includes the setup and gate script so you can inspect how the comparison works.
Keep the expectations and gate inputs under review. A matching response on those requests won’t cover a new requirement that the fixture never exercised. For the full comparison rules and exit behavior, use the replay verdict reference.
If you’re choosing a stand-in for one function, start with the mocking series. If the HTTP client and payloads are part of the test, use the proxymock capstone, then the CI example to prove a deliberately broken response fails.
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.
Whole-workflow LLM prompt
Read https://speedscale.com/blog/service-virtualization-vs-mocking/ and inspect my project instructions first. Choose the smallest test-double boundary for my stated behavior. Implement only the required state transitions and failure responses, assert the application's observable result, and keep a separate integration check for semantics the substitute cannot prove. Check installed tool help before adapting commands. Report the checks actually run, their results, and anything you could not verify.Frequently asked questions
When is a simple stub sufficient?
Use a stub when the test needs a small, explicit response or error from a dependency. A function-level stub suits isolated logic. A network stub also exercises the real client and serialization path.
Do virtualized services preserve mutable state?
Only when the tool and scenario implement it. WireMock and Hoverfly support explicit state mechanisms. A recorded response sequence does not provide arbitrary backend behavior; check the transitions, user isolation and reset rules your test needs.
Which integration checks still require the real dependency?
Use real test instances for provider-owned behavior such as database constraints, transaction semantics, authentication decisions and protocol compatibility. A mock checks how your caller handles selected responses; a separate integration check verifies the provider's behavior.