API Mocks

API mocks or test-doubles are an essential piece of the puzzle when it comes to testing micro-services. Very often, an API that you need to test depends on other APIs not owned by your team. In such cases, without mocks, you end up depending on end-to-end integration test environments where all APIs are deployed. This is not always feasible, especially when APIs are still in development, or when extra test-environments are un-stable or simply don’t exist. API mocks enable your team to move ahead without being constrained by the lack of test-environments. You can even have front-end teams work in parallel using mocks, while ensuring that the server-side teams are using the same contract. Karate’s unique value proposition of having API tests and mocks in the same framework using the same syntax, gives you a competitive advantage when it comes to delivering value in the API economy.

Karate API Mocks Key Features

Self Hosted

100% local no data in the cloud

Dynamic Responses

Handle state, simulate complex behavior

Git Friendly

Share and collaborate

Parallel Requests

Thread-safe even support performance test

Life-Cycle API

Embed in unit-tests or command line

Easy Install

Get started in minutes, minimal setup

Simple Syntax

No Programming experience needed

Clearly, you don’t need mocks if you don’t depend on any external service. You may not need mocks if the services you depend on:

  • Java knowledge is not required and even non-programmers can write tests
  • Scripts are plain-text, require no compilation step or IDE, and teams can collaborate using Git / standard SCM
  • Based on the popular Cucumber / Gherkin standard - withIDE support and syntax-coloring options

The classic situation where you need mocks is when the API or service you depend on is owned by a different team, and in extreme cases is even beyond the boundaries of your top-level organization.

You will need mocks in cases where a test-deployment of the service is not available or is so unreliable that it slows you down. Not having a “test environment” that is strong enough to handle performance testing is a common problem. And another extreme case is when the service you depend on is being developed at the same time - which means you have only two options - either wait for a version to appear and be deployed - or use some kind of mock.

When you evaluate an API mocking tool (some vendors refer to this as “Service Virtualization”) make sure that it can help you craft “high fidelity” mocks, else they will be very limited in their use.

img

With a good mocking strategy in place, you will be able to run your whole test-automation CI pipeline without needing to include 3rd party services into your deployments. This can be a huge competitive advantage for your team.

When you use an additional set of tests that play the role of contract-tests, this means that you can continuously trust the mock to be a valid replica of the real system that you ultimately depend on.