Service - Integration Testing: Difference between revisions
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
This service is intended to be run in a deployed AWS environment, all services and resources required for the integration tests need to be operational. | This service is intended to be run in a deployed AWS environment, all services and resources required for the integration tests need to be operational. | ||
= | = DynamoDB tables = | ||
== | == TestRecord == | ||
=== Fields === | |||
'''integrationTestTag''' ''(partition key)'' | |||
'''testStartedTimestamp''' ''(sort key)'' - time that the integration test was started/created. | |||
'''stages''' - an object that holds the details and status of each stage [[#TestRecord.stages structure]] | |||
'''testStatus''' - current status of the integration test, either '''processing''', '''passed''', or '''failed''' | |||
= Lambda Functions = | |||
== initiateIntegrationTest == | |||
<syntaxhighlight lang="JavaScript"> | |||
/** | |||
* Starts integration test/s | |||
* @param {string} [integrationTestTag] - Only initiate test with matching integrationTestTag | |||
* @param {string} [serviceName] - Only initiate tests where initialStage serviceName matches | |||
* @param {string} [resourceType] - Only initiate tests where initialStage resourceType matches | |||
* @param {string} [resourceName] - Only initiate tests where initialStage resourceName matches | |||
* | |||
* @returns {boolean} true if the test was initiated successfully, false if the test could not be initiated (? or an error thrown ?) | |||
*/ | |||
module.exports.getIntegrationTests = (serviceName, resourceType, resourceName) => { | |||
</syntaxhighlight> | |||
=== logic === | |||
# Invoke [[Service - Integration Test Config:getIntegrationTests]] to get configurations of all matching tests | |||
# for each integration test: | |||
## save a record into TestRecord table | |||
## store in a variable the config for the initialStage | |||
##: we do not want to send the initial request until all stages are saved into TestRecord table | |||
# for the initialStage: | |||
## build initial event to start the test using the initialStage's input event | |||
## invoke the initialStage's Lambda function | |||
= TestRecord.stages structure = | |||
<syntaxhighlight lang="JSON"> | |||
{ | |||
config: { | |||
//straight copy of this stage from integration test config | |||
}, | |||
status: waiting|passed|failed, | |||
results: { | |||
//detailed results for this stage | |||
} | |||
} | |||
</syntaxhighlight> | |||
= Initiating tests = | = Initiating tests = | ||
When the initial request is sent to begin an integration test the middleware LOG_LEVEL is set to DEBUG, this causes all Lambda functions and requests to external services to add a message to the services MsgOut queue. The Integration Testing service subscribes to these queues and uses these messages to monitor each stage of the workflow to ensure input and output is as expected, and that the request | When the initial request is sent to begin an integration test the middleware LOG_LEVEL is set to DEBUG, this causes all Lambda functions and requests to external services to also add a message to the services MsgOut queue. | ||
The Integration Testing service subscribes to these queues and uses these messages to monitor each stage of the workflow to ensure input and output is as expected, and that the integration test completes fully. | |||
Add the following Correlation Ids to the initial request so we can track the integration test and filter messages: | |||
.... which gets added to Message Attributes and can be used as a filter, so only debug messages that were initiated by Integration Testing are received by it. This will exclude requests that middleware randomly sets to debug. | |||
[[Category:Backend services| Integration Testing]] | [[Category:Backend services| Integration Testing]] |
Revision as of 02:10, 3 September 2020
Overview
Service that pulls integration tests from the Integration Test Config service, invokes each test and monitors the steps execute as expected.
This service is intended to be run in a deployed AWS environment, all services and resources required for the integration tests need to be operational.
DynamoDB tables
TestRecord
Fields
integrationTestTag (partition key) testStartedTimestamp (sort key) - time that the integration test was started/created. stages - an object that holds the details and status of each stage #TestRecord.stages structure testStatus - current status of the integration test, either processing, passed, or failed
Lambda Functions
initiateIntegrationTest
/**
* Starts integration test/s
* @param {string} [integrationTestTag] - Only initiate test with matching integrationTestTag
* @param {string} [serviceName] - Only initiate tests where initialStage serviceName matches
* @param {string} [resourceType] - Only initiate tests where initialStage resourceType matches
* @param {string} [resourceName] - Only initiate tests where initialStage resourceName matches
*
* @returns {boolean} true if the test was initiated successfully, false if the test could not be initiated (? or an error thrown ?)
*/
module.exports.getIntegrationTests = (serviceName, resourceType, resourceName) => {
logic
- Invoke Service - Integration Test Config:getIntegrationTests to get configurations of all matching tests
- for each integration test:
- save a record into TestRecord table
- store in a variable the config for the initialStage
- we do not want to send the initial request until all stages are saved into TestRecord table
- for the initialStage:
- build initial event to start the test using the initialStage's input event
- invoke the initialStage's Lambda function
TestRecord.stages structure
{
config: {
//straight copy of this stage from integration test config
},
status: waiting|passed|failed,
results: {
//detailed results for this stage
}
}
Initiating tests
When the initial request is sent to begin an integration test the middleware LOG_LEVEL is set to DEBUG, this causes all Lambda functions and requests to external services to also add a message to the services MsgOut queue.
The Integration Testing service subscribes to these queues and uses these messages to monitor each stage of the workflow to ensure input and output is as expected, and that the integration test completes fully.
Add the following Correlation Ids to the initial request so we can track the integration test and filter messages: .... which gets added to Message Attributes and can be used as a filter, so only debug messages that were initiated by Integration Testing are received by it. This will exclude requests that middleware randomly sets to debug.