chore(ci): move e2e utils into testing

[dreamorosi]

Description of your changes

This PR introduces cross-cutting changes to the integration tests for all utilities in the project. The main goals of this PR are two:

• Complete the move of code used to create, deploy, and run integration test CDK stack to the dedicated internal testing package
• Reduce duplication / verbosity of the code used to declare the test resources

In #1633 we have created an internal testing package that holds resources dedicated to deploy and run integration tests using CDK. Prior to this PR the package contained only the basic TestStack construct and a handful helper functions. Most of the actual logic used to add resources to a CDK stack was still scattered around the different packages of the workspace.

This PR almost completely removes the usage of custom functions/abstractions to create CDK resources in favor of following patterns suggested by CDK like composition and inheritance.

For instance, before this PR multiple utilities were defining their version of an helper function that looked something like this:

type CreateLambdaFunctionProps = {
  stack: Stack,
  id: string,
  runtime: string,
  handler: string,
  entry: string,
  ...
};

const createLambdaFunction = (props: CreateLambdaFunctionProps): NodejsFunction => {
  const fn = new NodejsFunction(props.stack, props.id, {
    runtime: props.runtime as Runtime,
    ....
};

This led to several different but similar implementations that created slightly different variations of the same type of resource.

With this PR the testing package offers a base CDK resource that extends the CDK L3 construct directly and that applies the same set of defaults across all tests:

class TestNodejsFunction extends NodejsFunction {
  public constructor(
    stack: TestStack,
    props: TestNodejsFunctionProps,
    extraProps: ExtraTestProps
  ) {
    super(stack.stack, `fn-${randomUUID().substring(0, 5)}`, {
      timeout: Duration.seconds(30),
      memorySize: 256,
      tracing: Tracing.ACTIVE,
      ...props,
      functionName: concatenateResourceName({
        testName: stack.testName,
        resourceName: extraProps.nameSuffix,
      }),
      runtime: TEST_RUNTIMES[getRuntimeKey()],
      logRetention: RetentionDays.ONE_DAY,
    });

    new CfnOutput(this, extraProps.nameSuffix, {
      value: this.functionName,
    });
  }
}

Different utilities (Tracer, Metrics, etc.) can then use this base L3+ construct and extend it further to apply specific configurations that are unique to that test/utility:

class TracerTestNodejsFunction extends TestNodejsFunction {
  public constructor(
    scope: TestStack,
    props: TestNodejsFunctionProps,
    extraProps: ExtraTestProps
  ) {
    super(
      scope,
      {
        ...props,
        environment: {
          ...commonEnvironmentVars,
          EXPECTED_SERVICE_NAME: extraProps.nameSuffix,
          EXPECTED_CUSTOM_METADATA_VALUE: JSON.stringify(
            commonEnvironmentVars.EXPECTED_CUSTOM_METADATA_VALUE
          ),
          EXPECTED_CUSTOM_RESPONSE_VALUE: JSON.stringify(
            commonEnvironmentVars.EXPECTED_CUSTOM_RESPONSE_VALUE
          ),
          ...props.environment,
        },
      },
      extraProps
    );
  }
}

In this way, in addition to having less code to maintain, we have the certainty that all the resources used during integration tests start from the same set of defaults.

The same pattern has been applied to DynamoDB tables and other resources that are used across different tests / utilities.

In addition to the benefits described above this, together with a handful new helper functions that allow to create unique resource names, also leads to more terse test setups.

The integration tests for this projects are run for different runtimes and utilities concurrently. This means that all resources from stacks to single AWS resources must have unique but identifiable names.

Another change brought by this PR is enforcing this constraint and making sure that all resources follow the same scheme: <Utility Name>-<runtime>-<uuid{0, 5}>-<human readable suffix>, i.e. Logger-E2E-node18-1dad3-AllFeatures-Decorator.

This is done with the introduction and rollout of a couple of helper functions that take in a prefix (the test name) and a suffix (the resource name) and generate the string by reading the test context.

Related issues, RFCs

Issue number: closes #1660

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
14.0% Duplication

[dreamorosi]

Successful integration tests run: https://github.com/aws-powertools/powertools-lambda-typescript/actions/runs/6052552726