LinkedIn
Twitter
In this article we look at how the new local Apigee Development feature can be used to run integration tests from within the local development environment and without having to deploy the proxies to Apigee first. In this example we are using the popular BDD testing framework Apickli for our BDD tests. For an example proxy with the corresponding Apickli tests see the Apigee DevRel CI/CD example. The concepts described in this article of course easily be applied to any other testing tool.
The benefits of behavior-driven development for designing and implementing resilient API proxies have been mentioned in this forum multiple times (e.g. General Testing Strategies) and are embedded in many CI/CD pipelines of Apigee customer to validate the correct end-to-end behavior of Apigee proxies when deployed within the whole API platform.
Before the introduction of the local Apigee Development feature (note that at the time of writing this feature is currently in BETA), API developers had to deploy their proxies to a development environment in order to be able to run end to end tests against them. The development lifecycle consisted of local unit testing and linting steps and the end to end tests that are executed against a deployed artifact. Even though this process ensures the most realistic and production-like end to end testing environment, it introduces additional latency and reduces the velocity in iterating against BDD tests when developing new features.
With the local Apigee development feature the API developer now has access to a containerized emulator that is capable of running Apigee proxies without having to deploy them to a full runtime. As described in the Getting Started section of the local development documentation, the emulator exposes the API proxies at a specific port for locally validating the functionality. It is immediately obvious that this endpoint can also be leveraged to run automated integration tests such as an Apickli test suite that we would have previously run against the deployed proxies.
To configure Apickli you will need to set the protocol, host and base path. Both the protocol and host are different for the local emulator environment and a remote deployment target. We are therefore using environment variables to allow the same Apickli tests to run against the emulator as well as the full Apigee deployments .
const apickliModule = require("apickli");
const { Before } = require("@cucumber/cucumber");
Before(function () {
const protocol = process.env.TEST_PROTOCOL || "https";
const host = process.env.TEST_HOST;
const basePath = process.env.TEST_BASE_PATH;
this.apickli = new apickliModule.Apickli(protocol, ${host}${basePath});
this.apickli.addRequestHeader("Cache-Control", "no-cache");
});
For our local development the TEST_PROTOCOL will be ‘http’ because TLS is (at the time of writing this article) not supported by the local emulator. The TEST_HOST will be the localhost plus the exposed port on the emulator container and the base path is set according to the proxy. For convenience, we can configure these variables in the package.json file as a script:
"scripts": {
//...
"integration-test-local": "TEST_PROTOCOL='http' TEST_HOST=localhost:8998 TEST_BASE_PATH=/demo/v1 cucumber-js --publish-quiet ./src/tests/integration",
//...
},
With this configuration in place we can run the local integration tests and iterate during the development phase against a locally deployed version of the API proxy:
npm run integration-test-local
> my-proxy-v1@1.0.0 integration-test-local
> TEST_PROTOCOL='http' TEST_HOST=localhost:8998 cucumber-js --publish-quiet ./src/tests/integration
...............................
6 scenarios (6 passed)
19 steps (19 passed)
0m00.155s (executing steps: 0m00.146s)
