Test environment overview

Test environments

There are three test environments to plan for:

Local

For example when a developer clones one repository to their local computer and wishes to test code within that one repository.

• Self contained environment per service/repository
• Does not have the AWS environment available
• Can use mock responses and environments if mocking modules function well
• Modules that emulate AWS offline are often lacking matching functionality/buggy
• DynamoDB / APIGateway / Lambda local mocking modules work well
• Mainly unit tests and basic integration tests that don’t involve queues, invoking other lambda functions, etc..

Test environment deployed on AWS

Can have multiple deployed test environments, eg one that refreshes seed data and runs automated tests, one as a sandbox where data can be manipulated as a sandbox environment.

• Replicates the final development environment
• Requires all services used in tested code to be deployed

Production environment deployed on AWS

This is the final live production service, tests that do not harm live data/state can be periodically executed to make sure production environment is functioning as expected.

• Can hook into live workflows (eg using selective/random requests set by middleware to debug or test) and for example check the flow passes through all steps

Idea - Hexagonal Architecture pattern

Split communication with other services into their own adaptors, so can insert tests for just the wiring (communication process), or just the logic (separating the logic outputs from the communication levels).

Should be easy to implement in serverless/queue design we have, eg by hooking into SNS queues.

Sharing tests across environments

Unit tests used in the local environment could be extended to be steps within deployed integration tests across services, if we break up the multi-step integration steps into each services components, those components could be the unit tests for each service. The expected data that passes between services during integration tests would become the mock responses, inputs, and expected outputs for the unit tests.

Doing this would allow us to code tests once, primarily for integration test, and have the same test design applied to each services unit tests. Single test designs used in multiple environments.

Increasing the number of unit tests is optimal because local unit tests will be the most often invoked and the first line of testing, more unit tests will mean faster detection of bugs and less resources used moving to deployed integration tests.

• Service - Integration Test Config
• Service - Integration Testing