{"id":7978,"date":"2021-08-18T08:30:00","date_gmt":"2021-08-18T05:30:00","guid":{"rendered":"https:\/\/dashbird.io\/?p=7978"},"modified":"2023-08-03T16:43:33","modified_gmt":"2023-08-03T13:43:33","slug":"test-javascript-lambda-functions","status":"publish","type":"post","link":"https:\/\/dashbird.io\/blog\/test-javascript-lambda-functions\/","title":{"rendered":"How to Test JavaScript Lambda Functions?"},"content":{"rendered":"\n

This article will discuss the different options for testing your AWS Lambda functions; the focus will be on JavaScript.<\/em><\/p>\n\n\n\n

Function as a service<\/a> (FaaS) offerings like AWS Lambda are a blessing for software development. They remove many of the issues<\/strong> that come with the setup and maintenance of backend infrastructure. With much of the upfront work taken out of the process, they also lower the barrier to start a new service<\/strong> and encourage modularization and encapsulation of software systems.<\/p>\n\n\n\n

Testing distributed systems<\/strong> and serverless cloud infrastructures<\/strong> specifically is always a source of long discussions. Some people prefer the local approach<\/strong> of emulating everything around your own code because it gives you fast iterations. Others say it gives you a false sense of safety because you\u2019re not really testing the actual services involved later when you deploy into your production environment.<\/p>\n\n\n\n

What Needs to be Tested?<\/h2>\n\n\n\n

First of all, your own code<\/strong>, obviously. <\/p>\n\n\n\n

But the main part in the architecture where FaaS really shines is integration code<\/strong>. Lambda can be seen as versatile glue between all the managed services AWS, and other vendors, have to offer. So, the main focus of tests isn\u2019t just your code<\/strong> but also how it integrates with different services<\/strong>. Having a Lambda that just reads an event and writes an output will be a rare occasion; usually, it will access one or multiple other services like S3, Step Functions, or RDS.<\/p>\n\n\n\n

Smoke Tests<\/h2>\n\n\n\n

Smoke tests are a straightforward type of test<\/strong>. They only check that your code doesn\u2019t crash when you try to run it<\/strong>. This means smoke tests don\u2019t check if your code works correctly<\/strong>. It could be that you have a bug in some if-branch anywhere that isn\u2019t executed with the test. It doesn\u2019t test for logic issues either.<\/p>\n\n\n\n

In terms of a web server<\/strong>, a smoke test would mean starting the server. No request gets sent to the server; just starting the server and see if it crashes. This is easy to do, and if it fails, you can save time running any other test.<\/p>\n\n\n\n

For Lambda<\/strong>, the action of starting and handling an event is the same because Lambdas only run when they handle an event and get frozen or retired right after they did their work. This means a smoke test would mean sending an event to the Lambda function<\/strong> to see if it throws an error. The simplest even you think your Lambda function should be able to handle would do. <\/p>\n\n\n\n

A smoke test can be done via the AWS CLI with the following command:<\/p>\n\n\n\n

$ aws lambda invoke \\\n--cli-binary-format raw-in-base64-out \\\n--function-name <LAMBDA_FUNCTION_NAME> \\\n--payload --payload file:\/\/<JSON_EVENT_FILE>\n<\/pre>\n\n\n\n
For automation purposes, you can add such CLI commands to a bash script and simply execute it before every other test runs.<\/p>\n\n\n\n
Unit Tests<\/h2>\n\n\n\n
Unit tests are a bit more complex<\/strong> than smoke tests because they actually test the logic of your function<\/strong>. Since most errors usually happen when integrating your code with other services, they don\u2019t bring that much value compared to integration tests.<\/p>\n\n\n\n
But sometimes, you have very complex logic inside a Lambda function that doesn\u2019t need to access other services. If it does access other services, the interaction with them is very basic.<\/p>\n\n\n\n
To get unit tests going, your first step is extracting the logic you want to test<\/strong> into a JavaScript module. <\/p>\n\n\n\n
Let\u2019s look at the following example of a Lambda function that adds or substracts two numbers depending on an operation argument.<\/p>\n\n\n\n
exports.handler = async (event) => {\n  if (event.queryStringParameters.operation === \"substract\")\n    return {\n      statusCode: 200,\n      headers: { \"Content-Type\": \"application\/json\" },\n      body:\n        event.queryStringParameters.x - \n        event.queryStringParameters.y\n    }\n\n  return {\n    statusCode: 200,\n    headers: { \"Content-Type\": \"application\/json\" },\n    body:\n      event.queryStringParameters.x + \n      event.queryStringParameters.y\n  }\n}\n<\/pre>\n\n\n\n
This is a contrived example, but still, the function is harder to test than it needs to be. We would have to create an event object containing the queryStringParameters<\/code> field, which would require an operation<\/code>, x<\/code>, and y<\/code> fields to be present.<\/p>\n\n\n\n
If we encapsulate this logic in a plain JavaScript function that only requires three arguments, things would be simpler. <\/p>\n\n\n\n
const addOrSubtract = (operation, x, y) => \n  operation === \"substract\" ? x - y : x + y;\n\nexports.handler = async (event) => {\n  const { operation, x, y } = event.queryStringParameters;\n\n  return {\n    statusCode: 200,\n    headers: { \"Content-Type\": \"application\/json\" },\n    body: addOrSubtract(operation, x, y)\n  };\n};\n<\/pre>\n\n\n\n
In this refactored example, we can now test the logic independently from the Lambda handler function.<\/p>\n\n\n\n
Integration Tests<\/h2>\n\n\n\n
Integration tests are the most important part of testing FaaS<\/strong>. I said it before, and I will repeat it, AWS Lambda<\/strong> is mostly used to glue together managed cloud services<\/strong>, and the parts where your Lambda function interacts with other services are the most crucial test targets<\/strong>.<\/p>\n\n\n\n
Now, there are two main ways of integration testing:<\/p>\n\n\n\n