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 tests and use that same configuration to build mocked unit tests in a local environment, pulling out only the steps that apply to a single service.

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

The configuration files separate different elements of the test to allow for re-use, as follows:

The repositories root directory has a sub-directory named test_config that holds user-configurable setup files, it has a services sub-directory and a tests.js file:

test_config/services

Holds service specific configurations, the services directory is separated into one sub-directory per service, the directory name matches each deployed service's iz_serviceName.

Each per services directory has a resources.js file and an events sub-directory:

test_config/services/{service name}/resources.js

Resources that are tested at one point during an integration test flow, for example one Lambda function.

test_config/services/{service name}/events

Expected input/output values that can be used to start tests and perform checks/tests. Any number of .js files can be added to this directory.

test_config/tests

Configures the tests, any number of .js files can be added to this directory.

resources.js Syntax

Has one module.exports function that returns an an object of all available resources, the structure is:

    {resource_type}: {
        {resource_name}:{
            //currently no settings added
        }
        ..
    }
    ..

events/*.js Syntax

For each step in an integration test that spans multiple resources there will be expected input and outputs, these are configured separately to the integration tests so that local unit test config for each service can extract just the configuration it needs, allows tests to branch into multiple paths, each being tested, and also offers re-use opportunities.

tests/*.js Syntax

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.