API Gateway Testing

Overview

The tests here can help verify and test that the service-router, service-conductor, and service-workers modules are configured and deployed properly in various environments (local/DEV, CI, QA, TEST, PILOT, PROD).

Tests for only the API Gateway are located in the build-tests/api-gateway Postman collection, which test the stack without calling microservices. Additional tests are included in the build-tests location for doing end-to-end testing through the API Gateway that make calls to the microservices.

There are also folders parallel to build-tests, such as "data-lake", etc. and a few build scripts of micros behind the gateway that use cccnext/jenkins-shared-library/vars/runApiGatewayTests.groovy and a call to runApiGatewayTests passing in folder name.

Note: These are a subset of unit tests each micro should have in their respective Git repos.

Testing the Gateway Stack

Consider this typical workflow of a call in the API Gateway:

         |------       API GATEWAY      -----|----  MICROSERVICE ---|------    API GATEWAY    ------|
(caller) > router > conductor > workers >  -=[some process]=-  > workers > conductor > router > (caller)

API Gateway Testing Requirements:

  1. API Gateway tests will not call actual microservice endpoints. Microservices are tested in the micro's Git repo.
  2. Every service that's deployed / exposed in service-router must be tested and pass these API Gateway stack tests.
  3. In the above workflow {{ some process }} merely returns a 200 OK if it received valid input.

Design Solution:

  • If service-router, all headers are passed through workflow to service-workers
  • When a service-worker polls for work and gets a task, it checks the HTTP headers passed. If a header named mock_service = true, then,
    • Instead of calling out to micro-service, the service-worker returns a 200 OK response

Requirement/Design Solution

  • Requirement 1: Handled by the new header and added workflow check in service-worker
  • Requirement 2: There's no link between the api-gateway-test Postman collection and the routes exposed in router; this will have to be code reviewed. We can fail the build for any result that comes back that is not a 200
  • Requirement 3: The service-worker for each task has a simple if check for the mock_service header and will return success if the header is true

Integration Tests

TODO: doc Postman folders, describing `build-tests' vs other folders

Postman

To add or modify the Postman collection and affect the Jenkins validation for the API Gateway stack, use the following steps:

  1. In Postman, import the API-Gateway.postman_collection collection and various API-Gateway-*.postman_environment.json environment files into Postman.
  2. Dev/test any changes in Postman. Make sure all environment files are in sync. Note: The 'DEV' environment uses a hostname 'localip' that's resolved on the command line when the image is run. Postman tests are likely to change frequently and customizing things like environment variables in the Git collection can lead to sync issues. Consider keeping any of your own custom Postman test collections in a separate location.
  3. Export the collection and environments from Postman into this module's postman/ directory.
  4. Build a local Docker image .
  5. Commit and push changes to your branch in Git, issue a pull request, and merge into develop.