Testing and Troubleshooting AWS CDK Applications

Testing is a crucial part of building reliable and performant applications, and developing CDK applications is no exception to that. If you speak to the developers working with me (Mark), they will make jokes about my obsession with writing tests. We don’t even necessarily enjoy the process of writing tests, although we must admit that watching green ticks appear when test scenarios are run is fun.

In this chapter, we will dive into the world of testing in the context of AWS CDK applications. Automated testing is essential for running a sanity check on your application and ensuring that the functionality and state of your application are as expected, even when new components are added or changed. We will focus on automated testing since manual testing can be time-consuming and error-prone, especially as CDK apps become more complex.

The primary purpose of automated testing is to run through a checklist of tests as quickly...

Technical requirements

Same as the previous chapters, you can find the code for this chapter in this book’s GitHub repository at https://github.com/PacktPublishing/AWS-CDK-in-Practice/tree/main/chapter-6-testing-and-troubleshooting-cdk-applications.

The code in this chapter is identical to the code in Chapter 5 except for the addition of some tests, which we will go through in this chapter.

The Code in Action video for this chapter can be viewed at: https://packt.link/Tp5R8.

Understanding the terms of testing

First, let’s get some of the definitions out of the way before we continue. Let’s start with the types of tests:

• Unit tests: Unit tests involve testing every function individually and making sure that, given a certain expected and unexpected input, the function responds with an expected output or a graceful error.
• Integration tests: Integration tests are a higher level of testing than unit tests and often involve various modules for each scenario. Some integration testing scenarios might involve various functions and modules that make sure these functions work well in tandem to deliver certain functionality.
• End-to-end (E2E) tests: These tests provide the highest level of testing, which often involves running test scenarios against a live system.
• Regression testing: These types of tests are run to find inconsistencies and broken behavior when the system changes.

I won’t go about arguing the case for...

Various ways of testing CDK apps

CDK testing is generally performed in one of two ways:

• Fine-grained assertions: These types of tests are similar to unit testing and are performed to detect regressions. They are conducted with the AWS CDK assertions module (found at https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.assertions-readme.html), which integrates with common testing frameworks such as Jest (https://jestjs.io/) and essentially tests that certain modules in our CDK app have certain properties – for example, a certain EC2 instance will have a specific AMI.
• Snapshot tests: Closer to integration testing, snapshot tests don’t care how you wire up your CDK application. They compare the output of a synthesized CDK stack to a previous state after changes have been applied. Snapshot tests are a great way to refactor your CDK application while making sure the outputs are the same (another way to deal with regression issues).

AWS recommends using...

Running the tests

This chapter’s code comes with a few fine-grained tests and snapshot tests preconfigured so that you can go through the exercise of running these tests. These tests are by no means exhaustive (meaning covering all the functionality) and this might not be the optimal way to configure tests in your project. However, hopefully, this will inspire you to improve. Let’s take a look at how to run this chapter’s tests.

Configuring the environments

Just like in the previous chapter, when we were running our CDK stack for various environments, we need to create a .env file in the infrastructure directory of chapter 6 to pass some values about the deployment to test the stack. We will name this file .env.testing so that it only gets picked up when we are running the tests. So, go ahead and create a .env.testing file under the infrastructure directory and fill it with values similar to the ones in the Chapter 5 .env files:

CDK_DEFAULT_ACCOUNT=<...

Examining CDK deployment logs

Another way to troubleshoot a CDK application is by looking at its internal logs. This is often useful if a certain resource gets stuck when being created, which, for example, happens when an ECS container fails to stabilize. In such situations, looking at the verbose CDK logs could shine a light on what is happening.

This can be achieved by passing the following flags to cdk commands:

• -v: Verbose
• -vv: Very verbose
• -vvv: Extremely verbose

For instance, when deploying using cdk deploy, you can see a lot more information about the status of the deployment if you pass in one of the aforementioned flags, like so:

$ cdk deploy --profile cdk -vv

There is also the -debug flag. The -debug flag is used to enable debug mode for the cdk command. It will cause the CDK to display additional debug information about the deployment process, including detailed information about the CloudFormation stack events and the individual AWS SDK calls...

Debugging CDK apps using VSCode

Debugging AWS CDK applications in VSCode allows you to easily identify and fix issues in your code. By using VSCode’s built-in debugging tools, such as breakpoints and the ability to step through code, you can quickly locate the source of any errors or bugs and make the necessary changes to resolve them.

Additionally, VSCode’s integration with AWS CDK makes it easy to set up and run debugging sessions, allowing you to quickly test and troubleshoot your code without having to switch between multiple tools or environments. Debugging in VSCode can save you time and improve the overall development process of your AWS CDK applications.

Debugging

Code debugging is not a feature that’s exclusive to VSCode and there are plenty of resources online on how to set up debugging for other code editors and tools.

To debug AWS CDK using VSCode, you need to set up a launch configuration in your launch.json file. To do that, within the...

Troubleshooting common problems with CDK

As you embark on your journey of coding CDK applications, you may encounter certain challenges that are common among CDK beginners. In this section, we will address some of these challenges and provide effective remedies to overcome them.

Bootstrapping

A common issue when using CDK is deploying to a new environment, which may result in an error stating that the environment has not been bootstrapped. Bootstrapping refers to deploying a pre-created AWS stack to a specific Region. This is necessary to set up the required resources for deploying any stack, S3 buckets, ECR repositories, and so on. As you may recall, we had to deal with this at the beginning of this book.

To resolve this issue, you can use the following command:

$ cdk bootstrap

You will have to do this everytime to you deploy a CDK project in new AWS accounts.

IAM permissions

When deploying a stack or setting up an environment, AWS resources are created, and it...

Summary

In this chapter, we learned about various types of software testing and how testing in CDK is performed using fine-grained assertions and snapshot tests. We learned how, by using them, we can protect sensitive components of CDK applications. We also learned how to examine CDK deployment logs when facing issues. Finally, we learned how to debug our CDK applications in VSCode, as well as troubleshoot common issues. In the next chapter, we will step into the world of serverless development using CDK.