Run in CI Pipelines

Updated 3 weeks ago by Rahul Lahiri

At this point, you have created the service tests and run them locally. You may have setup the decision rules as well. Now, we are going to run the service test created earlier in a test environment. The test can be initiated either from the API Studio UI, or from your CI.

Cloud test driver

In order to use the Mesh Dynamics cloud based test driver, the endpoint in CI must be reachable from the test driver in the cloud. The service test will be run with the target service running in the test environment with all producer services mocked. The two requirements to run the service test in the test environment are:

  • The Mesh Dynamics test drivers must be able to send the test requests to the service in test environment.
  • The service under test can be configured to send egress requests from the service under test to the Mesh Dynamics mocks servers.

Local test driver

If the endpoint in CI cannot be accessed from the public cloud, the test driver must run in the customer's VPC. Mesh Dynamics provides a container that can be deployed in the customer's VPC to drive the test requests.

CI test driver using Mesh Dynamics container locally

The test container makes requests to the Mesh Dynamics cloud for test data, and drives the test using the data.

Configure egress requests for mocking

Configure the egress requests from the service to be sent to the Mesh Dynamics mocks services. Any egress call to service <service> at https://<host>/<api> should be replaced by :

https://app.meshdynamics.io/api/mst/<token>/<customer/<app>/<instance>/<service>/<api> 

Description of the fields:

Field name

Details

token

Customer-specific API access token issued by Mesh Dynamics

In the near term, please contact Mesh Dynamics to get your API access token. It will be available from the API Studio soon.

customer

Customer name used for the account.

In the near term, please contact Mesh Dynamics to get the customer name. It will be available from the API Studio soon.

app

The name of application. It is shown in the 'Application' dropdown at the top of the page. The application name is case sensitive.

instance

Derived from the gateway endpoint. The name must be converted to replace the '.' with the '_' character.

Example:

Gateway endpoint: https://ci.endpoint.meshdynamics.io

Request parameter: https://ci_endpoint_meshdynamics_io

service

Service name specified during recording

Example

For our example service, MovieInfo, we need to change the egress URI definitions in the MIRest.conf as follows:

BOOKDETAILS_URI=https://app.meshdynamics.io/api/mst/<api-token>/CubeCorp/MovieInfo/fd7a15005fa5.ngrok.io/details
BOOKRATINGS_URI=https://app.meshdynamics.io/api/mst/<api-token>/CubeCorp/MovieInfo/fd7a15005fa5.ngrok.io/ratings
BOOKREVIEWS_URI=https://app.meshdynamics.io/api/mst/<api-token>/CubeCorp/MovieInfo/fd7a15005fa5.ngrok.io/reviews
RESTWRAPJDBC_URI=https://app.meshdynamics.io/api/mst/<api-token>/CubeCorp/MovieInfo/fd7a15005fa5.ngrok.io/restwrapjdbc/restsql

Test from API Studio

You can use the API Studio UI to initiate a service test.

  1. Go to the test runner screen by clicking on the icon.
  1. Click on Select Instance to select an existing configuration, or select Other to run the test against a user-defined endpoint.
  1. Enter the endpoint to send requests to in the Gateway End Point box. For our example, let's send the requests to https://moviebook.meshdynamics.io.
  1. From the Select Golden dropdown, select the test suite: GL_movieinfo_service_test
  2. From the Service dropdown. select the service under test. The test driver will only issue the requests to this endpoint. <Add image>
  3. Start the test by clicking the Run Test button
  4. When the test finishes, the results will be available in the results section

Run from CI

The test can be initiated by issuing a cURL command from a test script. Here is an example cURL command. Notice that this cURL command specifies the API paths to be tested with the 'paths' parameters. Only the specified paths for the target service will be included in the test.

curl 'https://app.meshdynamics.io/api/rs/start/Recording-1390394666' \
-H 'Connection: keep-alive' \
-H 'Accept: application/json, text/plain, */*' \
-H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJyYWh1bC5sYWhpcmlAY3ViZWNvcnAuaW8iLCJyb2xlcyI6WyJST0xFX1VTRVIiXSwiaWF0IjoxNjEwNTg5Nzg1LCJleHAiOjE2MTA2NzYxODV9.MId8d1Ro3W8cMTsmJ6I_0Dv0pkRO9rNhR4LONRNo4IA' \
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-raw 'endPoint=https%3A%2F%2Fmoviebook.meshdnamics.io&instanceId=moviebook.meshdnamics.io&templateSetVer=DefaultMovieInfo&userId=username%40meshdynamics.io&testConfigName=Other&analyze=true&storeToDatastore=true&mockServices=RestWrapJDBC&mockServices=Reviews&mockServices=Details&mockServices=Ratings&paths=minfo%2Flistmovies&paths=minfo%2Fliststores&paths=minfo%2Frentmovie&paths=minfo%2Freturnmovie&paths=minfo%2Flistmovies&paths=minfo%2Fliststores&paths=minfo%2Flogin&paths=minfo%2Fgenre-group&paths=minfo%2Fgenre-groups&paths=minfo%2Fdelete-genre-group%2F*&paths=minfo%2FgetMovieList&paths=minfo%2Fcategories&paths=minfo%2FdeleteRental' \
--compressed

Here is another example cURL command. In this example, there are no 'paths' parameters. So all paths for the target service will be tested when using this configuration.

curl 'https://app.meshdynamics.io/api/rs/start/Recording-1390394666' \
-H 'Connection: keep-alive' \
-H 'Accept: application/json, text/plain, */*' \
-H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJyYWh1bC5sYWhpcmlAY3ViZWNvcnAuaW8iLCJyb2xlcyI6WyJST0xFX1VTRVIiXSwiaWF0IjoxNjEwNTg5Nzg1LCJleHAiOjE2MTA2NzYxODV9.MId8d1Ro3W8cMTsmJ6I_0Dv0pkRO9rNhR4LONRNo4IA' \
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-raw 'endPoint=https%3A%2F%2Fmoviebook.meshdnamics.io&instanceId=moviebook.meshdnamics.io&templateSetVer=DefaultMovieInfo&userId=username%40meshdynamics.io&analyze=true&storeToDatastore=true&mockServices=RestWrapJDBC&mockServices=Reviews&mockServices=Details&mockServices=Ratings&service=minfo' \
--compressed

The key parameters supported in the cURL command are explained below.

The required vs. optional characteristics are defined from the perspective of service tests. The requirements are different for end-to-end tests.

Item

Type

Description

Authorization

Auth token to allow execution of the request

endPoint

Required

The endpoint for issuing the request

instanceId

Required

Required for CI in order to execute the test in a pre-defined instance

templateSetVer

Required

Comparison template to use. Typically it would be 'Default' followed by the application name

userId

Required

email address of the user

testConfigName

Optional

Test configuration

analyze

Required

'True' means the results should be compared against the baseline and the decision rules should be applied

mockServices

Optional

For service testing, we assume that all egress services are mocked. The specification is used primarily for record keeping purposes for future reference. It does not alter the system behavior.

paths

Optional*

The API paths for the target service that should be tested. If the test file contains other API paths that are not specified in these parameters, then those API paths will not be tested.

If no path parameters are specified, then all the API paths of the specified service are tested.

*Note: One of either paths or service parameters must be specified, and only one of these parameters should be specified. See below.

service

Optional*

The service parameter specifies the service to be tested. If you do not specify the paths parameters, then you must specify the service parameter to indicate the service to be tested.

*Note: One of either paths or service parameters must be specified. Otherwise the test driver will try to run every API request in the test suite. See above.

You can also specify both service and paths. This is only required if the same path exists in multiple services. By specifying both, you can limit the testing only the correct service/path combination.

storeToDatastore

Optional

Use this flag to have the test driver log requests/responses if no listeners are deployed. Set: &storeToDatastore=true

dynamicInjectionConfigVersion

Optional*

Use this configuration parameter if your service test requires context propagation. In most case, the setting will be: &dynamicInjectionConfigVersion=Default<App>

For example, for the sample app here, the configuration parameter would be:

&dynamicInjectionConfigVersion=DefaultMovieInfo


How did we do?