Service - Integration Test Config
Overview
This service is intended to be used both for offline local unit testing individual services, and for multi-step/multi-service deployed integration tests.
Using this service we can configure integration, and use those same tests in a local environment, pulling out only the steps that apply to a single service and turning them into de-coupled unit tests.
The main purpose of this service is to configure integration tests for the current project that will then be used by either the local test environment or deployed by the Integration Testing service
The reasoning behind splitting integration test configuration into a separate service, rather than incorporated into each individual service, is to keep the main services lean and remove code duplication. Tests that pass from one service to another will have shared details, the expected output from one will be the expected input the other.
Repository Structure
... (to be added)
Constructing Tests
For each step in an test that spans multiple resources there will be expected input and outputs, these are configured separate to tests so unit test config for each service can point to just the data in needs, also allowing tests to branch out into multiple paths, each being tested.
The test config specifies which points to monitor and what to test for.
Set Tests To Not Invoke in Production Environment
Local Test Environment and Test Environment Deployed on AWS want to invoke as many tests as possible, including tests that can be invoked in the Production Environment Deployed on AWS, however the Production environment wants to strictly restrict tests to ones that affect the live project such as by changing state.
This separation of tests could be achieved by having a different configuration of tests for Test environments vs Production, another option that reduces managing test configs in two locations is finding a clear way to differentiate which tests are not done in Production.
This could be achieved by placing the tests in different files (so it is cleared for developers which they are adding), and using the iz_stage environment variable to choose which files to load as available tests.