Today, software development teams are tasked with integrating their products with seemingly every system, component, and operating system under the sun. Unfortunately, it might not be desirable or even possible to access those systems during development. Security, performance, or maintenance issues could make them unavailable. Teams are having dependencies on services owned by other groups that are not accessible, halting development.
This is when you mock, stub, or virtualize. What’s the difference?
In the world of software development, stubbing creates a stand-in for an app or service but only mocks the behavior and not the entire object. Mocking takes it a step further, creating a fake version of an external or internal service or app that can stand in for the real one, helping your tests run more quickly and reliably. Mocking enables development and QA teams to simulate and model the behavior of complex, interdependent, and often unavailable or limited services. Virtual services go further, virtualizing behavior and properties of downstream applications and services, ensuring teams can develop or test internal or external applications with absolutely zero limitations.
Mocking for Every Stage of the SDLC
Mocking supports all the stages of the software development lifecycle (SDLC). For functional tests, a basic mock of the component to be tested can be more than enough to get testing efforts started. For more advanced non-functional testing when security and performance testing is needed, this is where a mock can handle the capacity, bandwidth, and error responses. For external components, as in microservice architectures, make sure that when you are testing different integrations or APIs, it’s all going to work cohesively. Instead of using an actual external API, using a recording as a mock returns known results to your component. When APIs are made available to consumers to try them before committing to use them, a simulation of the API can be provided – online or as a distributable for local deployment.
The web continues to be the leading API use case, with mobile and backend system integrations close behind. Backend and integration systems are also big use cases for mocks, especially in microservices architecture.
Why Mock?
But why go through the effort of building a mock when you could spend that time testing?
Mocking is the foundation of shifting left. Mocking allows 1) developing and testing in parallel and 2) finding defects faster. Of course, the further down the SDLC you get, the more expensive and time-consuming errors become. Full-scale test case coverage is key. Also, if your service or a partner’s integration service crashes when you use a mock, there’s no downtime. Mocking reduces costs, time delays, and errors and mistakes while providing better test coverage, round-the-clock access to service endpoints, and testing and developing in parallel.
Common Use Cases
The most common use cases for mocking are 1) external services such as partner integrations which are not available for testing. You can mock and not to have interact. 2) Internal services which are outside of your ownership or control – a microservice outside of your business unit or business domain. 3) Services are not yet developed. Do not wait for someone else to give you the service – simply mock and then test. 4) Services are not robust.
In the case of bringing an external service local to your system, large-scale performance tests against a service like Facebook user logins, Google cloud logins or Microsoft logins can be quite limiting, including not getting the expected interactions. You can also be charged for every interaction done to that endpoint. Whether it’s hundreds of thousands or millions of transactions per second, you can get the required responses, record them, and then virtualize with mocking. You can then test at any point with one system – no dependencies.
Testing Every Component
We need to test every single component offered – whether it’s inside or outside of our business domain or using a partner integration. You need to test earlier in the SDLC to be able to find, track, and resolve defects. Though the big benefit of mocking is shifting left, context is also important because if you don’t know what that third-party API is doing, how are you going to expect it to react the way you need it to?
If issues or changes arise at any point along the SDLC, you can stand up a mock and continue testing with no downtime. Simply put, mocks make life for development teams more flexible.
