concept performance testing in category microservice
This is an excerpt from Manning's book Testing Microservices with Mountebank.
Creating test data test-by-test doesn’t work well for manual testers, it doesn’t work if multiple testers are hitting the same virtual service, and it doesn’t work in situations (like performance testing) where you need a large batch of data. To address these concerns, you can configure the virtual service to read the test data from a persistent store. With the test-by-test approach to test data creation, all you have to do is tell the virtual service what the next response should look like. With a data store, you will need some way of deciding which response to send based on something from the request. For example, you might send back different responses based on identifiers in the request URL (figure 1.11).
All of the tests we’ve looked at up to this point have attempted to prove system correctness, but with performance tests, the goal is to understand system behavior more than to prove its correctness. The understanding gained from performance testing does help to improve correctness through unearthing bugs (such as memory leaks) in the application, and it helps to ensure that the operational environment of the application is capable of supporting expected loads. But no application can support infinite load, and stress testing in particular is designed to break the application by finding the upper limits of capacity. While that’s happening, a certain degree of errors is expected in many kinds of performance testing. The goal is to verify system behavior in aggregate rather than verify each service call independently. Performance tests often help define service level objectives—for instance, that a service responds within 500 milliseconds 99% of the time under expected load.
Performance testing can be difficult. Fortunately, mountebank is there to help.
Figure 10.1 looks like many other diagrams you have seen already, and for good reason. Performance testing sits within a class of problems that requires a more deterministic approach to testing an application with nondeterministic runtime dependencies. I hope by now you can spot exactly the class of problems that service virtualization aims to help. It’s a problem that says “if the rest of the runtime ecosystem is more stable than my application, then I can determine the performance characteristics of my application.” Service virtualization helps ensure that the application is the weakest link in the runtime ecosystem.