Skip to main content

Service Mocking

Most non-trivial applications rely on external systems like 3rd party APIs or databases to function. This is especially true for apps that utilize microservices architectures. Mocks can be generated by hand or automatically by Speedscale. Examples of services that could be mocked include the Google API, postgres or another team's HTTP REST endpoint.

How does it work?​

Service mocks are generally made available over the network and are accessible to your app in a test environment or on the local desktop. If your service mocks are working properly, your service under test (SUT) will believe it is actually running in production because the mock is convincing. A realistic service mock must simulate the following components:

  • data that is similar to production
  • realistic response time (not too fast, not too slow)
  • accurate response sequencing for non-idempotent transactions
  • continuously updated tokens like authentication, etc

What kind of dependencies can be automatically mocked?​

Speedscale automatically mocks any technology on our supported technology page. Once traffic is recorded, it is turned into mocks via Snapshot.

What if Speedscale cannot automatically mock my dependency?​

You can request new protocol support in the Speedscale community Slack. Otherwise, you will need to provide your own replica of the dependency. Typically this involves writing a custom mock server using a framework like Mockito or gomock. For databases this gets a lot more involved and will require database replication tools.

What are some of the downsides of service mocking?​

Custom built service mocks tend to fall out of date quickly because the data or the API contract changes. For this reason we recommend Speedscale regenerate your mocks automatically every sprint (if possible).

For more information see our tutorial on mock APIs.