API Mocking
Rapid Development
Integration is highly dependent on other parties, sometimes slowing the speed of delivering features via our APIs. However, it is easy to mitigate this slowdown, especially at an early development stage and in lower integration environments, like Dev.
Vendor Dependency
At the start API development, you should be getting familiarized with vendor service specifications and documentation. From my experience, the best developer experience has APIs available online. Most problems arise in custom-tailored APIs, either because API specification is not up to date or because examples are missing.
Once we have our mapping, we should try the scenario as soon as possible. At this step, we are highly dependent on the vendor and their early access environment, like sandbox, test, etc. You will sometimes have to wait weeks for a limited sandbox environment. In the meantime, we can introduce a mocking service that is called by our API until the actual vendor API is available.
Advantages:
- Early access to test APIs
- Higher quality of delivered integration
- Less dependency on vendor
- Low overhead of switching to actual API implementation
- Higher control on example request/response returned by mocked service
- Lower cost on vendor test environment provisioning (depending on the vendor)
Disadvantages:
- Higher overhead as we need to prepare mocking request/response
- Not perfect responses
- Minor mismatches between actual API and mocked API due to imperfect vendor API documentation
Integration Dependency
Now, consider the APIs that we deliver to the consumers. We deliver experience APIs, so we are dependent on the consumers. How do we provide the best developer experience for them?
MuleSoft contains a great design toolset on the Anypoint Platform. On the diagram below, you can see the design part comprising of Design, Simulate, Feedback, and Validate steps. This cycle provides high-quality API specifications that we share with consumers.
During this process, we can expose early-access mocking in the Feedback step. Anypoint Platform has an out-of-the-box mocking capability for API assets. You just need to provide the request and response example in your API spec (raml). Once it is there, consumers can do early testing without having the API implementation ready. We can quickly receive feedback and make proper amendments to the API specification by applying the next cycle of the design phase.
Advantages:
- Early-access to experience API
- Higher quality of API specification by rapid feedback and design amendments
- Higher quality of delivered integration
- Loosen dependency between consumer and integration team
- Better developer experience (good API spec and test service to call)
- Low overhead of switching to actual API implementation
Disadvantages
- Higher overhead as we need to prepare mocking request/response
- Not perfect responses
Quality of Service
Unit Tests and Mocking
Unit testing is a suggested best practice that has many advantages. MUnits are integrated with MuleSoft’s Anypoint Studio. Any MuleSoft developer can easily learn how to use MUnits, as it is built on top of well-known building blocks (event processors). You can even generate unit tests during your debug sessions .
The MUnit framework provides the ‘Mock When’ event processor. You can easily specify which event processor in your flow to mock and provide either a static or dynamic response. This is also the first place the developer prepares a request/response.
Anypoint Platform Mocking
As mentioned earlier, Anypoint Platform has mocking capabilities. Mock services are available for your API specification in Design Center and for APIs published on Anypoint Exchange. Read here to learn how to enable this.
This is important, especially when we want to deliver API specifications to consumers as quickly as possible. Developers can start assessing our API specification and prepare the initial source code.
You should remember that mocks delivered by Anypoint Platform are limited. They are based on static examples prepared in API specification. If more than one example is present, it is returned in a round-robin manner by the mock.
Mocking Service
Incorporating mocking services allow us to have the most freedom. It can be used to mock vendor APIs so we can test our system APIs. We can even use it to mock our experience APIs and enable consumers to use the service at the early development stage. Why do I mention here experience APIs? Even though we have mocking capabilities on the Anypoint Platform, they are fairly limited. Most of the 3rd party mocking services give greater flexibility in constructing dynamic requests/responses.
Summary
Introducing a mocking service can significantly reduce dependency on vendors and consumers of experience APIs. Developers usually use them to mock external calls during unit tests. Using mocks in a lower environment reduces the time to start testing and increases overall solution quality.
I recommend using a mocking service. From my real-life experience, I know that many vendors offer very limited testing environments with extra constraints. This can impede the testing and impact the quality of the solution. We can easily overcome this by introducing mocks.
