AWS CDK and Tests

Now we need to talk about testability! AWS CDK gives us unique selling points and mechanisms related to testing.

Before we move forward, we need to talk about testability. AWS CDK gives us unique selling points and mechanisms related to testing. Let’s review them!

The main problem with the Feedback Loop

If you are working with the AWS CloudFormation, you probably do not need to read another paragraph at all – you already feel the pain.

When working with templates and iterating with infrastructure scripts, time is crucial. In most cases, we need to update or create a stack, wait, and we will discover errors in the runtime one by one. This is tedious, problematic, and wasteful.

With pure CloudFormation, you have to fallback to additional tools or use a totally different tool (e.g., Terraform) to achieve testability and shortening the feedback loop.

Luckily, we have exciting options related to testing tools.

Unit Testing in AWS CDK

We need to start with an explanation that the unit tests are verifying the generated output and templates. This may sound like a simplistic and crude approach, but actually, it allows for more, as we can perform the following elements:

  • Evaluating differences and snapshots (which represents the frozen state of the infrastructure graph after synthesis).
  • Very precise assertions about resources and their state.
  • Testing validation rules (e.g., length of the attributes – like name, and similar), passed parameters, and constructs.

We will see all those techniques in practice in future blog posts!


Please bear in mind that all about we talked do not invalidate the need for integration tests. It helps with testability. It shortens the feedback loop and allows us to build a safety net for our infrastructure scripts and infrastructure as code.

By Wojciech Gawroński

Principal Cloud Architect at Pattern Match. Infrastructure as Code, DevOps culture and AWS aficionado. Functional Programming wrangler (Erlang/Elixir).

2 replies on “AWS CDK and Tests”

Hi Wojtek, don’t you have a feeling that quite often CDK testing end-up testing CDK itself? e.g. creating an explicit stack with a couple of resources and then testing the existence of those resources… So far I was able to see value in those tests only for custom constructs and more sophisticated `factories` of various infrastructure elements. Will you share your thoughts where you see a real value for this?

Hey Piotr! You are right – in many cases, it looks like testing CDK inside out instead of testing our infrastructure scripts. It’s a similar situation like with doing unit testing for the sake of doing it.

However, I still think that the most significant value comes from a proper organization into constructs and then testing their behavior. TBH this post is just a sneak-peek, and I will share more practical examples in the later posts. Additionally, I have planned to elaborate here about those techniques later.


This site uses Akismet to reduce spam. Learn how your comment data is processed.