Three Tips for Writing CDK Tests

1. Use the assertions module

Something of a no-brainer, but use the tools you’re given! One of the best parts of the CDK library is the assertions module. It contains two sections. One for “fine-grained” assertions, like what you would write during unit testing. The other is for performing “snapshot” tests, in which you compare the new template against one that is already deployed. It’s a section of the library that can be easily missed but provides so much value when used correctly.

2. Make any Nested Stacks easily accessible

One of the benefits of using CDK is the ability to create declarative dependency trees. But, testing the implemented Nested Stacks can be tricky. One of the best ways I’ve found to simplify this is to add Nested Stacks as properties of the Stack class that handles deploying them. For example…

import SubStack from 'substack-stack.ts';

export class TopStack extends Stack {   
  constructor(scope, id, props) {     
    const subStack = new SubStack(this, 'substack', props);   
  } 
}

Is pretty standard. While it is possible to test this, you can simplify the process by “stashing” a reference.

import SubStack from 'substack-stack.ts';

export class TopStack extends Stack {   
  subStack: SubStack;    
  constructor(scope, id, props) {     
    this.subStack = new SubStack(this, 'substack', props);   
  } 
}

Now accessing this for fine-grained assertions can look like…

import { Capture, Match, Template } from "aws-cdk-lib/assertions";
import * as cdk from "aws-cdk-lib"; 
import { TopStack } from "top-stack";  

describe("TopStack", () => {   
  test("has the substack", () => {     
    const app = new cdk.App();      
    const topStack = new TopStack(app, "topStack", {});     
    const { subStack } = topStack; // we pull the substack through the property      

    // Pass the subStack to template.     
    const template = Template.fromStack(subStack);   
  } 
}

3. Write your template to a file (sometimes)

While writing assertions, you can find situations where the tests are failing for reasons that may not make sense. When this happens, one of the first things I will do is write the CloudFormation template out into a file. This way you can get a cold hard copy of what it is you are building in your hand. Rather than trying to parse through complex logs or mysterious error messages. Not a guarantee but often getting to see the complete output can solve many common testing pitfalls.

Conclusion

Testing is great! Testing your infrastructure… Even better! If you’re just getting started with CDK or if you’ve been around since the early days, I hope these tips can help you along your journey! If you have any tips you'd like to add, share them in the comments. Always looking to learn more!

Find me on LinkedIn | Github