Sven the Barbarian at 09:07, 9 August 2020

2020-08-09T09:07:01Z

@@ Line 26: / Line 26: @@
 * 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
 = Sharing tests across environments =
@@ Line 45: / Line 37: @@
 * [[Service - Integration Test Config]]
 * [[Service - Integration Testing]]

Sven the Barbarian: Created page with "= Test environments = There are three test environments to plan for: == Local == For example when a developer clones one repository to their loca..."

2020-08-09T08:13:53Z

Created page with "= Test environments = There are three test environments to plan for: == Local == For example when a developer clones one repository to their loca..."

New page

= Test environments =

There are three test environments to plan for:

== [[Local test environment|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]]

Test environment overview - Revision history

Sven the Barbarian at 09:07, 9 August 2020

Sven the Barbarian: Created page with "= Test environments = There are three test environments to plan for: == Local == For example when a developer clones one repository to their loca..."