Service Testing with Mesh Dynamics

Updated 3 months ago by Rahul Lahiri

Mesh Dynamics supports service testing by developers from their laptops, as well as running service tests in CI. We first outline the underlying process. Then we will go over the differences in the setup for each of these use cases. In addition, the setup needs to change depending on whether you are using a Kubernetes environment (which does the service discovery for you), or an environment where you need to do the service discovery yourself.

Process overview

The process of creating service tests includes:

  1. Creating test requests for the APIs exposed by the service, and creating a collection with the test requests.
  2. Converting the collection to a test suite. Mesh Dynamics automatically creates accurate mocks for the egress requests and corresponding responses.
  3. Add context propagation rules, if necessary. Mesh Dynamics identifies and suggests rules by learning from the API data.
  4. Running the test suite once to generate sample test results.
  5. Adding decision rules to the test suite. Mesh Dynamics identifies and suggests rules by learning from the original and test run data.

The service tests created can subsequently be run from either the developer's laptop, or in CI.

The test suite must be updated as new test cases are identified, as APIs evolve, or additional capabilities are added.

Local vs CI

Local setup

The following configuration is used for running service tests locally from the developer's laptop with the service under test running in the developer's IDE.

  • Mesh Dynamics' cloud test driver drives the requests to the local copy of the service running in the developer's laptop through ngrok.
  • Egress requests go to the API Studio proxy, which accesses the cloud mock service.
  • The results are sent to the Mesh Dynamics cloud service.
While we expect that the egress requests from the API Studio are served by the Mesh Dynamics mock services, there may be cases where you would need to use live APIs for certain services. The egress request configuration in API Studio supports this configuration flexibility.

You may need to change the egress request configurations for your service to send the requests to the API Studio. In addition to the configuration change, you need to run ngrok to be able to forward the requests from the cloud test driver to the local instance of the service under test.

CI Setup

In the CI setup, Mesh Dynamics cloud test driver drivers the requests directly to the service. The service configurations for egress requests must be setup to be sent to the Mesh Dynamics cloud services.

In the case where CI runs on an internal network without access from the Mesh Dynamics cloud, we would need to either run the test driver in your CI cluster, or use ngrok to forward the requests from the cloud test driver to the service.

Kubernetes vs Docker

If you are using Kubernetes for deployment, or a Docker deployment that uses pre-determined service endpoints / ports, then you can specify the endpoint url for the services. Docker deployments that use dynamic service endpoints and rely on service discovery need to be handled differently. Testing in an environment with dynamic Docker deployments will be covered in a separate article.

How did we do?