Maintenance: review e2e test utilities

[dreamorosi]

Note
This issue was originally opened specifically for the Access Grant Aspect mentioned here, however there are more items that we should review from the integration tests so I have expanded the scope of the issue.

Summary

The integration / e2e tests are the result of many iterations over almost two years. With more utilities being added to the toolkit and more AWS resources to integrate with, some aspects of the utilities written to support the tests can be reviewed and improved.

As part of this task we should survey the code related to the deployment, running, invocation, and assertions of the integration tests and find areas of improvement.

Why is this needed?

The current implementation works, but readability and maintainability can be improved.

Which area does this relate to?

Tests

Solution

Not known yet, however it's likely that we'll have to create a number of smaller issues from this one.

Acknowledgment

• This request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Python, Java

[dreamorosi]

Currently as part of the integration tests of the Parameters utility we are creating a number of resources. These resources need to be accessed by one or more Lambda functions that is using the utility. This allows us to test the utility in a real world scenario and increase our confidence on its correctness.

Due to how the test harness is structured, we initially opted for a CDK Aspect that would grant access to said resources to a given function.

The logic and types of the aspect have however been sprawling and if we were to add any additional resource type both readability and maintainability would decrease.

While working on this, maybe also simplify/review the names of the tests in the AppConfigProvider test, i.e.:

test: 'get-freeform-json-binary',

could become:

test: 'get-json-freeform-transform-json',

as well as the test numbers.

[dreamorosi]

Another area to improve is the function currently called createStackWithLambdaFunction (here) which is used to create a CDK stack with one Lambda function in it.

The function was written at a time when only the core utilities existed, and as such, we didn't have the necessity of deploying other AWS resources.

Now that we have to deploy different types of resources for other utilities that interact with AWS, the function could be extended or rewritten into an utility that allows to easily create a stack with a function as well as any additional resource needed for that specific test

Ideally this helper should be able to also handle naming the resources with unique names that share a prefix and also handle resource access grant - both tasks currently handled in the specific tests and repeated multiple times.

[dreamorosi]

An additional area of improvement could be to revisit the invokeFunction (here) which is used to call the Lambda function for a specific test.

Similar to the comment above, the function was written at a time where the payload sent to the function was standard across the test surface. With more utilities being added we needed more flexibility, and for this reason the code has become hard to maintain and convoluted.

We should streamline the function and make it more flexible (or more simple by delegating more responsibility to the caller).