Service - Integration Test Config - Revision history

Mint: /* dynamodb */

2025-11-24T07:24:53Z

dynamodb

← Older revision		Revision as of 07:24, 24 November 2025
Line 171:		Line 171:

	<syntaxhighlight lang="JavaScript" inline>keyValues</syntaxhighlight>: for DynamoDb events these are the primary key/s used to get the record that will be tested.		<syntaxhighlight lang="JavaScript" inline>keyValues</syntaxhighlight>: for DynamoDb events these are the primary key/s used to get the record that will be tested.



	== Local unit tests - Lambda requests ==		== Local unit tests - Lambda requests ==

Mint: /* events/.js Syntax /

2025-11-24T02:49:08Z

events/*.js Syntax

← Older revision		Revision as of 02:49, 24 November 2025
Line 82:		Line 82:
	the events directory can have any number of .js files, each file must export an EventConfig function, which returns an object of any number of event configurations.		the events directory can have any number of .js files, each file must export an EventConfig function, which returns an object of any number of event configurations.

			==event==
	Example:		Example:

	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	module.exports.EventConfig = () => {		module.exports.EventConfig = () => {
Line 115:		Line 115:
	},		},
	throwError: true\|false, //default: false, if set to true tests will expect this event to be a thrown error		throwError: true\|false, //default: false, if set to true tests will expect this event to be a thrown error
			},
			..
			}
			};
			</syntaxhighlight>

			==dynamodb==
			<syntaxhighlight lang="JavaScript">
			module.exports.EventConfig = () => {
			return {
			{eventTagDynamoDB}: {
			properties:{
			{propertyName}:{
			value: ".."
			forStageMatching: true\|false, //default: false, whether this property is used to match stage config during integration tests
			testValueMatches: true\|false, //default: true, whether value of this property is checked when performing test
			stringified: true\|false, //default: false
			//others, eg greater_than, substring etc..
			isObject: true\|false, //default: false, if is an object will look for child properties
			eventValue: // set to a fixed value, child properties are not processed individually
			useIsEqual: true\|false, //default true, used with eventValue only, if true uses _.isEqual to test value matches, (needed for arrays/objects)
			properties: // if is set to isObject: true, nest levels using properties
			isStringSet: true\|false, //default: false, DynamoDB events only, if the property is a String Set which needs to be formatted special
			},
			..
			},
	keyValues: { //DynamoDB only		keyValues: { //DynamoDB only
	{key1 attribute name}: ".. value of key1 attribute",		{key1 attribute name}: ".. value of key1 attribute",
	{key2 attribute name}: ".. value of key2 attribute"		{key2 attribute name}: ".. value of key2 attribute"
	},		}
	~~noRecord: true\|false, //default: false, DynamoDB only~~		}
			}
	},
	..
	}		}
	};		};
	</syntaxhighlight>		</syntaxhighlight>


	<syntaxhighlight lang="JavaScript" inline>{eventTag}</syntaxhighlight>: unique tag name for this event.		<syntaxhighlight lang="JavaScript" inline>{eventTag}</syntaxhighlight>: unique tag name for this event.
Line 142:		Line 166:
	<syntaxhighlight lang="JavaScript" inline>stringified</syntaxhighlight> allows for certain properties to be stringified, if is true the result will be parsed before checking the value, and AWSMock will stringify the value before returning.		<syntaxhighlight lang="JavaScript" inline>stringified</syntaxhighlight> allows for certain properties to be stringified, if is true the result will be parsed before checking the value, and AWSMock will stringify the value before returning.

	<syntaxhighlight lang="JavaScript" inline>snsSqsTrigger</syntaxhighlight> sets whether the resource is trigger by SNS > SQS flow.		<syntaxhighlight lang="JavaScript" inline>snsSqsTrigger</syntaxhighlight>: sets whether the resource is trigger by SNS > SQS flow.

			<syntaxhighlight lang="JavaScript" inline>eventTagDynamoDB</syntaxhighlight> :unique tag name for this event dynamodb.

	<syntaxhighlight lang="JavaScript" inline>keyValues</syntaxhighlight>: for DynamoDb events these are the primary key/s used to get the record that will be tested.		<syntaxhighlight lang="JavaScript" inline>keyValues</syntaxhighlight>: for DynamoDb events these are the primary key/s used to get the record that will be tested.

	~~<syntaxhighlight lang="JavaScript" inline>noRecord</syntaxhighlight>: for DynamoDb events this specifies that no record should exist for the given keyValues.~~

	== Local unit tests - Lambda requests ==		== Local unit tests - Lambda requests ==

Mint: /* tests.js Syntax */

2025-11-21T02:56:16Z

tests.js Syntax

← Older revision		Revision as of 02:56, 21 November 2025
Line 190:		Line 190:
	resourceType: {resourceType},		resourceType: {resourceType},
	resourceName: {resourceName},		resourceName: {resourceName},
	snsServiceName: ".." // name of the SNS service that deployed the snsTopic, so can build topic's full resource name		snsServiceName: ".." //[optional](sns) name of the SNS service that deployed the snsTopic, so can build topic's full resource name
	snsTopic: ".." // name of the SNS topic that triggers this resource, used when snsSqsTrigger = true		snsTopic: ".." //[optional](sns) name of the SNS topic that triggers this resource, used when snsSqsTrigger = true
	invokes: [ //resources that are invoked from this stage		invokes: [ //resources that are invoked from this stage
	{		{
	~~serviceName: {ServiceName},~~		eventStageTag: "zzz" //references another stage in this integration test
	~~resourceType: {resourceType},~~
	~~resourceName: {resourceName},~~
	~~inputEventTag: {eventTag}, //event that is sent to the invoked resource~~
	~~outputEventTag: {eventTag} //expected return value from the invoked resource~~
	},
	{
	eventStageTag: ~~{eventStageTag}~~ //references another stage in this integration test
	},		},
	..		..
Line 207:		Line 200:
	dynamodbOutputEventIdentifiers: [		dynamodbOutputEventIdentifiers: [
	{		{
	serviceName: {~~ServiceName~~}, //service that deployed the DynamoDB table, so can build table's full resource name		serviceName: {tableName}, //service that deployed the DynamoDB table, so can build table's full resource name
	resourceName: {resourceName}, //DynamoDB resourceName		resourceName: {resourceName}, //DynamoDB resourceName
	eventTag: {~~eventTag~~}		eventTag: {eventTagDynamoDB}
	},		},
	..		..
	],		],
	},		},
			{
			eventStageTag:"zzz"
			serviceName: {ServiceName},
			resourceType: {resourceType},
			resourceName: {resourceName},
			inputEventTag: {eventTag}, //event that is sent to the invoked resource
			outputEventTag: {eventTag} //expected return value from the invoked resource
			}
	..		..
	]		]
Line 231:		Line 232:

	== Set tests to not invoke in production environment ==		== Set tests to not invoke in production environment ==
			(old)

	[[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.		[[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.

Mint: /* tests.js Syntax */

2025-04-04T01:35:32Z

tests.js Syntax

← Older revision		Revision as of 01:35, 4 April 2025
Line 228:		Line 228:
	<syntaxhighlight lang="JavaScript" inline>snsTopic</syntaxhighlight>: for integration tests if snsSqsTrigger is true and snsTopic is set for the initial stage then the initial request will be published to this SNS topic. If snsSqsTrigger is true and snsTopic is not set we could generate a well formed Lambda event to simulate Records sent from SQS queue, another option would be an sqsQueue property where we send the initial stage as a message to the Lambda's SQS queue.		<syntaxhighlight lang="JavaScript" inline>snsTopic</syntaxhighlight>: for integration tests if snsSqsTrigger is true and snsTopic is set for the initial stage then the initial request will be published to this SNS topic. If snsSqsTrigger is true and snsTopic is not set we could generate a well formed Lambda event to simulate Records sent from SQS queue, another option would be an sqsQueue property where we send the initial stage as a message to the Lambda's SQS queue.

	<syntaxhighlight lang="JavaScript" inline>~~dynamoDbOutput~~</syntaxhighlight>: when processing the output event results, if dynamoDbOutput is set we also query DynamoDB tables and compare the results match each DynamoDb event listed here.		<syntaxhighlight lang="JavaScript" inline>dynamodbOutputEventIdentifiers</syntaxhighlight>: when processing the output event results, if dynamoDbOutput is set we also query DynamoDB tables and compare the results match each DynamoDb event listed here.

	== Set tests to not invoke in production environment ==		== Set tests to not invoke in production environment ==

Mint: /* tests.js Syntax */

2025-04-04T01:33:39Z

tests.js Syntax

← Older revision		Revision as of 01:33, 4 April 2025
Line 205:		Line 205:
	..		..
	],		],
	~~dynamoDbOutput~~: [		dynamodbOutputEventIdentifiers: [
	{		{
	serviceName: {ServiceName}, //service that deployed the DynamoDB table, so can build table's full resource name		serviceName: {ServiceName}, //service that deployed the DynamoDB table, so can build table's full resource name

Mint: /* resources.js Syntax */

2025-04-03T09:46:06Z

resources.js Syntax

← Older revision		Revision as of 09:46, 3 April 2025
Line 61:		Line 61:
	localHandler: ".. name of the modules handler function" //Lambda only		localHandler: ".. name of the modules handler function" //Lambda only
	functionName: ".. name of deployed Lambda functions" //Lambda only		functionName: ".. name of deployed Lambda functions" //Lambda only

	~~tableName: ".. name of deployed table" //Dynamodb only~~
	},		},
	..		..

Mint: /* resources.js Syntax */

2025-04-03T09:27:51Z

resources.js Syntax

← Older revision		Revision as of 09:27, 3 April 2025
Line 56:		Line 56:

	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	{resourceType}: {		{resourceType}: { // Lambda
	{resourceName}:{		{resourceName}:{
	localLocation: ".. location relative to project's root directory" //Lambda only		localLocation: ".. location relative to project's root directory" //Lambda only
Line 66:		Line 66:
	..		..
	},		},
	..		{resourceType}: { // Dynamodb
			{tableName}:{
			tableName": "ZZZZ", // tableName
			},
			},
			..
	</syntaxhighlight>		</syntaxhighlight>

Mint: /* tests/.js Syntax /

2025-04-03T09:05:25Z

tests/*.js Syntax

← Older revision		Revision as of 09:05, 3 April 2025
Line 161:		Line 161:
	When a deployed Lambda is triggered by an SQS queue we do not receive a returned value (only test for thrown errors so can manage retries), we could adjust our code to return an array of results from the logic for each record, in deploy environment we could catch this in the middleware and send integration test messages, in local unit tests we could test against the handlers returned value. For middleware would perhaps need to attach this to the Records object for each message so can accurately match the return value to the correct message.		When a deployed Lambda is triggered by an SQS queue we do not receive a returned value (only test for thrown errors so can manage retries), we could adjust our code to return an array of results from the logic for each record, in deploy environment we could catch this in the middleware and send integration test messages, in local unit tests we could test against the handlers returned value. For middleware would perhaps need to attach this to the Records object for each message so can accurately match the return value to the correct message.

	= tests/*.js Syntax =		= tests.js Syntax =

	Configures the integration tests, including the initial entry point and what events to monitor and perform tests on.		Configures the integration tests, including the initial entry point and what events to monitor and perform tests on.

Sven the Barbarian at 23:26, 8 March 2025

2025-03-08T23:26:21Z

← Older revision		Revision as of 23:26, 8 March 2025
Line 10:		Line 10:

	[[Developer guide for making Integration Tests]].		[[Developer guide for making Integration Tests]].

			= Repository =

			https://bitbucket.org/izara-core-testing/izara-core-support-services-integration-test-config

	= per Project Repositories =		= per Project Repositories =

Sven the Barbarian: /* Overview */

2025-02-11T04:40:45Z

Overview

← Older revision		Revision as of 04:40, 11 February 2025
Line 8:		Line 8:

	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.		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.

			[[Developer guide for making Integration Tests]].

	= per Project Repositories =		= per Project Repositories =

Service - Integration Test Config - Revision history

Mint: /* dynamodb */

Mint: /* events/*.js Syntax */

Mint: /* tests.js Syntax */

Mint: /* tests.js Syntax */

Mint: /* tests.js Syntax */

Mint: /* resources.js Syntax */

Mint: /* resources.js Syntax */

Mint: /* tests/*.js Syntax */

Sven the Barbarian at 23:26, 8 March 2025

Sven the Barbarian: /* Overview */

Mint: /* events/.js Syntax /

Mint: /* tests/.js Syntax /