aws-cdk has a library of testing utilities that are useful for asserting against stacks. The cdk repo uses it itself for a lot of its own unit tests.

https://www.npmjs.com/package/@aws-cdk/assert

This allows you to do something like

// jest
test('configurable retention period cannot exceed 14 days', () => {
  const stack = new MyStack();
  expect(stack).to(haveResource('AWS::SomeService::SomeResource', {
    SomePropertyOnResource: 'some-value-it-should-have'
  }));
});

This is only supported for CDK apps written in typescript as of now, but the plan is to eventually support all languages cdk supports.

Whether or not you should do this usually is similar to asking whether you should unit test any codebase. If you have a lot of complex business logic happening that does things like conditionally creating resources or otherwise changing your apps behavior, its probably worth getting some coverage in those places. If your app is essentially a bunch of static declarations without conditionals, loops, etc, maybe you can get by with just running cdk diff when making changes and manually verifying your expected changes.

If you're writing custom constructs for reusing in different cdk apps, unit testing those is probably a good idea.

Some relevant docs https://docs.aws.amazon.com/cdk/latest/guide/testing.html

An approach that I use, is to create a different project delegated to use the resources that i expect that have been created.

So, from the cdk-init-cluster project, i simply create all the necessary resources using cdk library. Than, after the DEPLOY phase, i run the cdk-init-cluster-test module that is delegated to populate/query/use the resources previously created from the cdk-init-cluster project.

This approach, can only help with few type of resources such as:

• S3 bucket
• Lambda
• AppSync
• DynamoDB table

The test project is in charge to:

• Populate the DynamoDB table and retrieve the data.
• Call the Lambda function with dummy data
• Call the lambda function with correct data for verify permission behaviour
• Call appsync (that wrap all the resources above) and verify the result

Then, i remove the data inserted for test. If no exceptions occurs, the test is passed.