How Service Mocking Enhances Internal Developer Platforms
With the growing prevalence of cloud-native environments, platform teams’ infrastructures are increasingly dependent on various integrated APIs, microservices, and third-party applications. Managing and ensuring best practices within your ecosystem can reduce cognitive load, and it relies on your ability to help developers parse through the expected outputs and inputs of your services and applications. Service mocking is simply a method of simulating application behavior and responses to better integrate, test, and improve your internal developer platform tools and applications.
Your external services have response sets, error-handling patterns, and decision-making processes that can be difficult to understand and handle without detailed testing, even with extensive documentation. Service mocking enables you to create a sandbox environment to test all possible outcomes without constraints like rate-limited services, higher costs for testing with live services, slower responses and feedback, and generally less control over application behavior.
In this article, you’ll explore service mocking, what it means to your engineering teams, the different approaches to implementing service mocking, and lastly, how service mocking improves your final software quality by being included in Internal Developer Platforms.
Service Mocking
Service mocking involves creating copy versions of services that behave similarly to the original versions but are entirely controlled by you. Your mock service will incur little to no costs compared to the original version, allowing you to test functionality, version control, interactions, and error handling without limitations in your development environments. This increases the coverage and quality of your tests while improving developer experience.
Service mocking produces data that is similar to what you might find in your production situations, with realistic timelines for responses. However, it’s particularly useful because you have an isolated environment to explore individual services and how they can work together within your ecosystem. This can reduce cognitive load and provide a developer portal. You can explore services you are dependent on and test interactions with the rest of your infrastructure without the need for live versions.
For example, in an e-commerce platform, you might want to explore the interaction between its infrastructure and Stripe as a payment processor, whether to test and implement more features during the software development process or to improve the customer experience during payments. Testing with the live Stripe service would incur costs and give you less control over the requests and responses going between your application and Stripe.
Different Approaches to Service Mocking
Development teams can use different approaches to simulate services during software delivery:
Manual mocking
If you’re familiar with the service you are trying to copy and have a clear understanding of its functionality as well as the expected outputs and inputs of the service, you can create mock objects and code functions that mimic the service behavior and give similar responses. For example, while exploring the GitHub REST API documentation, you might see that its responses are in JSON format and understand the number of fields given for specific requests. Before engaging the API, you can create sample responses and write code to parse through the expected JSON file and display the necessary fields. Most APIs and third-party services have in-depth documentation that showcases sample code, expected inputs, and the formatting of their responses.
Mock servers
Open Source Tools such as MockServer and WireMock allow you to script behavior for standalone servers from which you can set up expected actions and responses to simulate the behavior of APIs or services. For example, rather than testing your system architecture with its external dependencies (such as payment processors, databases, and messaging systems), you can code a mock server where you’ve modeled all the responses and requests that your external services produce. This allows developers and devops teams to test without incurring external charges, and you also have a stable, isolated environment in which to run various use cases and tests without external limitations.
Traffic replay
You can use traffic replay tools to record actual interactions within your infrastructure and replay these genuine requests and responses in another environment. An e-commerce platform might need to explore how its services hold up during high user volume periods. Rather than utilize junk data, you can replay all your genuine user orders and payments within a smaller time frame to overload your system and observe its behavior and results. Since it provides you with “production-grade” data for your tests, traffic replay allows for more seamless integration and realistic test results.
Each approach has its own advantages based on the needs of your software delivery process. While manual mocking might have more maintenance overhead, it provides in-depth control. Mock servers allow for more complicated scenarios and simplify the testing procedure. Lastly, traffic replay tools can act as a service catalog using actual recorded interactions to give you realistic behavior simulations.
Learn how traffic-driven replay testing is next generation
How Does Service Mocking Enhance an Internal Developer Platform?
Service mocking as part of your reference architectures can ensure your services are efficiently integrated for all possible interactions, thus improving software quality and easing infrastructure management. It’s especially useful in unit testing, where you test individual components or functions, and as a load testing best practice, where environments and data are a frequent bottleneck. It can also act as ephemeral environments in Internal Developer Platforms, where you use temporary environments for software engineering or testing.
Unit Testing
Unit tests focus on testing individual units of code in isolation. With service mocking, you can create a production-like environment for testing where realistic data is being used and where you have complete control over inputs and outputs without relying on external dependencies. This isolated environment can increase developer productivity, allowing you to quickly identify any deviations and predict results in testing as you can ensure the setting, requests, and responses are stable while other variables are changed.
With service mocking, you can simulate core components, including edge cases and error conditions, which might be challenging to replicate with the live version of these services. Many third-party services, also, have services and functions that they depend on, whether for data or computation. Your mock services will be less complicated as a result and offer faster and more efficient software development by speeding up the testing process and enabling more rapid iterations.
Load Testing
Platform engineers may not be able to predict how much use your infrastructure will get, which is why you need to stress test your services and applications with large amounts of traffic to understand how your systems will behave. With service mocking, teams can generate realistic user interactions and requests and simulate high traffic volumes to explore how your infrastructure scales with the increased load.
Load testing with mock services allows for a detailed analysis of your resource utilization and application’s response times. You have complete control of traffic, so you can focus on specific functions, endpoints, or requests to explore performance bottlenecks and the full behavior of your system without putting real users at risk or incurring costs from third-party services.
Ephemeral Environments
The use of ephemeral environments in platform engineering as Internal Developer Platform tools is one of its most important differentiators from traditional monolithic engineering. Ephemeral environments are temporary, disposable environments created for software engineering or testing purposes. As they are meant to be short-lived and agile, they offer a faster feedback loop. Your code is executed, a contained environment is made, your task or test is carried out, and you receive a failure or success message with details in your logs. Iterations are swift and flexible.
Ephemeral environments created with service mocking can be tailored to your specific testing needs, giving you greater control over the interactions of your services (simulated or otherwise). Mocking and modeling a service’s dependencies can lead to better isolation. Additionally, your service’s mocked environments can be built to be more resource-efficient, removing extraneous requests and behaviors while enabling fast test iteration and better resource management overall.
Check out our comprehensive comparison of Developer Environments, how they work, and who they’re best suited for
Case Studies
Service mocking can be especially useful for large companies to prototype, test, and iterate on new features quickly. Facebook has its own built-in service mocking solution that enables its devops team to automate tests and test all integrations into its infrastructure before going into live production.
Digibee
Cloud-native iPaaS (integration platform as a service) solution Digibee provides a no-code API studio that’s dependent on multiple services and applications working together. As its business and customer base grew, Digibee needed a faster and more efficient way to test its API integration software for deployment, as its previous use of UI tests and manual API test scripts was slow and inefficient. Digibee utilized Speedscale to automatically create mocks and traffic replays of outbound and inbound traffic. This allowed Digibee to isolate individual services from its backends and external dependencies and monitor its performance and behavior for a variety of simulated incoming requests. As a result, Digibee was able to swiftly validate its version control, regression issues, performance, and API contracts.
ContainIQ
ContainIQ, a specialized platform for Kubernetes observability and management, also adopted Speedscale to speed up development. The company used Speedscale to automate testing for its Google-Cloud-based infrastructure. It captured traffic over time from its primary gateway and used that to isolate and test golden paths with genuine traffic data collected for use in its simulated testing scenarios. This also made it easier and faster to validate changes made in development without stress testing with real customer traffic. ContainIQ also uses GitHub Actions with its Speedscale-collated traffic and mocks to carry out automated validation for every change made to its code repository. This proactive approach saves ContainIQ time and resources and allows the team to ship new features and functionalities with confidence.
Conclusion
This article explored service mocking, including its benefits to your Internal Developer Platform, Platform Engineering, and the different approaches to creating a mock service, such as manual mocking and mock servers. The article also explained how service mocking increases the speed of the feedback loop and testing iterations and provides predictive control over interactions within your infrastructure. This, in turn, leads to improved overall software quality.
Speedscale is a platform for automated testing, traffic-driven testing, service mocking, and observability. It helps you create and test software quickly with simulated production conditions and realistic data traffic. It’s your one-stop shop for tests, environments and data.