How to Speedup Your CDK Test Feedback
Speed up Your CDK Test Feedback Loop with Test-Driven Lambda Function DeploymentAre your CDK test cycles dragging due to lengthy lambda function bundling? Discover how to expedite feedback loops by skipping bundling during tests. In this blog, I will show you how you can skip the bundling when you run your tests.
Published May 8, 2024
When you deploy lambda functions using CDK and a test-driven approach, you might have noticed that the test feedback takes longer each time you add a new function. That’s because each function will be bundled with its own set of dependencies. These dependencies need to be downloaded before CDK can bundle them into a single package.
Before you can deploy your infrastructure you need to synthesize your code. This will transform your code into a CloudFormation template plus some assets. When you have a lambda function the content of this function will be bundled into one of these assets.
This all makes sense when you deploy your code. You need to ship the actual lambda code to AWS in the correct format with the correct dependencies. Otherwise, your solution will not work.
But the synth step is also used when you test your infrastructure code. The process is like the deploy step. Instead of deploying your templates, you will inspect the outcome. For example, you are expecting a Lambda function. This function will use a certain runtime. And, for production environments, you want to confirm that the backup tags are applied.
It might be an obvious answer. Skip the bundling when you run the tests! Assume we use the following code to create a Lambda function:
You can see that we are loading the code from a folder called sample_function. Then we pass the options on how CDK needs to bundle the function:
- First, the dependencies will be downloaded and installed.
- Next, the content from the sample_function is copied.
- The content of the asset_output folder will be the bundled function.
Now, these steps will become part of the test. You can skip the bundling by defining the test as followed:
A few things are happening in this example:
- When the app object is being created, some specific context is supplied. This context will overwrite the aws:cdk:bundling-stacks option. This means that the bundling options are overwritten with nothing.
- Then the stack object is created and a template is synthesized.
- We will confirm that we have a lambda function with the Python 3.12 runtime.
- We will also confirm that the DynamoDB table has the Backup tag with the value YES.
Because we skipped the bundling the test will execute immediately. Giving you instant feedback on the code that you have been writing. You can now run the test after each change. This enables you to create a nice development cycle:
- Adding a test implementation.
- Adding the business logic.
- Running the tests to confirm the implementation.
- Repeat
When you write tests you should confirm your business logic. The bundling logic has already been tested by the team that is maintaining CDK. So you don’t need to test it and it’s safe to skip the bundling.
You could argue that the options in the bundling need validation too. And yes, that is now skipped. Yet the bundling of these functions is usually always the same for each runtime. And when you deploy you will catch any bundling mistakes anyway. Next to that, you have tests for your lambda code as well. These tests are not executed against the bundled version of your code. These are executed against the source version of your code. So there is no need to bundle them from a testing perspective.
When it takes too long to run tests, you will run them less. This has a negative impact on your quality and efficiency. You can solve this by excluding heavy operations. Operations like downloading dependencies and bundling your lambda functions. This also helps with focussing on the tests that matter. The tests that actually confirm your business value.
Follow me if you want to learn more about improving your efficiency and code quality.
Photo by Pixabay