Service - Integration Testing - Revision history

Sven the Barbarian at 23:26, 8 March 2025

2025-03-08T23:26:31Z

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

	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.

			= Repository =

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

	= DynamoDB tables =		= DynamoDB tables =

Sven the Barbarian at 03:30, 19 August 2021

2021-08-19T03:30:46Z

← Older revision		Revision as of 03:30, 19 August 2021
Line 97:		Line 97:

	These new resource types could be an initial stage in the test configuration, when running integration tests the request would be sent to those resources (eg REST request to API Gateway or publish to SNS queue), on local unit tests we would need to build the triggered Lambda function directly, we could do this by following the invoke setting in the initial stage's config to find the triggered Lambda/s and building the event object for them.		These new resource types could be an initial stage in the test configuration, when running integration tests the request would be sent to those resources (eg REST request to API Gateway or publish to SNS queue), on local unit tests we would need to build the triggered Lambda function directly, we could do this by following the invoke setting in the initial stage's config to find the triggered Lambda/s and building the event object for them.

			= Bash script to invoke initiate tests =

			<syntaxhighlight lang="bash">
			declare -a groupTests=(
			'{ "serviceName": "Permission", "resourceType": "Lambda", "resourceName": "CheckPermission"}'
			'{ "serviceName": "Permission", "resourceType": "Lambda", "resourceName": "CheckPermission", "integrationTestTags": ["valueMatchCheck_oneRule_AnyCanPass_MustPassTrue__pass"] }'
			'{ "serviceName": "Permission", "resourceType": "Lambda", "resourceName": "CheckPermission", "integrationTestTags": ["serviceCheck__oneRule__basic__targetUserId_admin__pass"] }'
			)

			stage="Test"
			region="us-east-2"

			for test in "${groupTests[@]}"; do
			echo "=================================="
			echo "start one set of tests"
			echo ${test}

			#... invoke InitateTests....
			aws lambda invoke \
			--function-name "IntTesting${stage}InitiateIntegrationTestHdrInv" \
			--invocation-type Event \
			--payload "${test}" \
			--log-type Tail response.json \
			--cli-binary-format raw-in-base64-out \
			--region=${region}
			done
			</syntaxhighlight>

	= Working documents =		= Working documents =

Sven the Barbarian at 03:26, 14 May 2021

2021-05-14T03:26:16Z

← Older revision		Revision as of 03:26, 14 May 2021
Line 73:		Line 73:
	= 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 also~~ add ~~a message to the services Out topic.~~		When the initial request is sent add the following Correlation Ids to the initial request so we can track the integration test, filter messages, etc.:

	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, filter messages, etc.:

	; intTest-tag		; intTest-tag
Line 83:		Line 79:
	; intTest-time		; intTest-time
	: matches the test's testStartedTimestamp		: matches the test's testStartedTimestamp
			; intTest-serviceName
			: this services name, so other functions can generate the integration test topic names to send messages to

	These can also be used in production environment to exclude requests that middleware randomly set to debug from requests initiated by Integration Test service.		These can also be used in production environment to exclude requests that middleware randomly set to debug from requests initiated by Integration Test service.

			The Integration Testing service monitors each stage of the workflow to ensure input and output is as expected, and that the integration test completes fully.

			When a lambda receives a request that has these correlation ids it generates the integration test topic name by using the intTest-serviceName + stage + hardcoded topic name.

	= Ideas =		= Ideas =

Sven the Barbarian at 12:41, 3 May 2021

2021-05-03T12:41:12Z

← Older revision		Revision as of 12:41, 3 May 2021
Line 73:		Line 73:
	= 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 also add a message to the services ~~MsgOut queue~~.		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 Out topic.

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

Sven the Barbarian at 00:09, 15 January 2021

2021-01-15T00:09:28Z

← Older revision		Revision as of 00:09, 15 January 2021
Line 85:		Line 85:

	These can also be used in production environment to exclude requests that middleware randomly set to debug from requests initiated by Integration Test service.		These can also be used in production environment to exclude requests that middleware randomly set to debug from requests initiated by Integration Test service.

			= Ideas =

			== More granular resource types ==

			Currently API Gateway and SNS-SQS queue triggers for Lambda's are wrapped into the lambda event and test stage configurations, we could pull these out as separate resources that invoke the Lambda resource.

			This would more clearly compartmentize each resource, increase configuration re-usablilty, and allow us to more clearly add additional tests, for example subscriptions to the SNS queues.

			These new resource types could be an initial stage in the test configuration, when running integration tests the request would be sent to those resources (eg REST request to API Gateway or publish to SNS queue), on local unit tests we would need to build the triggered Lambda function directly, we could do this by following the invoke setting in the initial stage's config to find the triggered Lambda/s and building the event object for them.

	= Working documents =		= Working documents =

Sven the Barbarian: /* TestRecord */

2020-11-10T01:48:18Z

TestRecord

← Older revision		Revision as of 01:48, 10 November 2020
Line 7:		Line 7:
	= DynamoDB tables =		= DynamoDB tables =

	== ~~TestRecord~~ ==		== TestRecords ==

	=== Fields ===		=== Fields ===

Sven the Barbarian at 11:53, 4 November 2020

2020-11-04T11:53:37Z

← Older revision		Revision as of 11:53, 4 November 2020
Line 88:		Line 88:
	= Working documents =		= Working documents =

	[[:Category:Working_documents - Integration Testing\| Working_documents - Integration Testing]]		[[:Category:Working_documents - Integration Testing\|Working_documents - Integration Testing]]

	[[Category:Backend services\| Integration Testing]]		[[Category:Backend services\| Integration Testing]]

Sven the Barbarian at 11:53, 4 November 2020

2020-11-04T11:53:17Z

← Older revision		Revision as of 11:53, 4 November 2020
Line 88:		Line 88:
	= Working documents =		= Working documents =

	[[:Category:Working_documents - Integration Testing\|Working_documents - Integration Testing]]		[[:Category:Working_documents - Integration Testing\| Working_documents - Integration Testing]]

	[[Category:Backend services\| Integration Testing]]		[[Category:Backend services\| Integration Testing]]

Sven the Barbarian: /* Working documents */

2020-11-04T08:42:42Z

Working documents

← Older revision		Revision as of 08:42, 4 November 2020
Line 88:		Line 88:
	= Working documents =		= Working documents =

	[[:Category:Working_documents - Integration Testing]]		[[:Category:Working_documents - Integration Testing\|Working_documents - Integration Testing]]

	[[Category:Backend services\| Integration Testing]]		[[Category:Backend services\| Integration Testing]]

Sven the Barbarian: /* Working documents */

2020-11-04T08:42:08Z

Working documents

← Older revision		Revision as of 08:42, 4 November 2020
Line 88:		Line 88:
	= Working documents =		= Working documents =

	[[:Category:Working_documents~~\|Working documents~~]]		[[:Category:Working_documents - Integration Testing]]

	[[Category:Backend services\| Integration Testing]]		[[Category:Backend services\| Integration Testing]]