Test the Handler First: How to Get Immediate Results for Your Testing Efforts
Get more bang for your testing buck
This is the second post in the series, “5 Strategies for Serverless Testing”. Check out the first post here. If you like this content, feel free to share and subscribe!
A very effective way to test your serverless applications is to focus on the inputs and outputs coming in and out of your Lambda function.
For every Lambda, you want to know that given payload X, you reliably get Y as a response. This of course forces you to spend some time defining (and documenting) what X and Y should look like, and all of their potential permutations.
The diagram above represents a very simple service which is in charge of returning geocoordinates given an address. You can see how both the input and the output are clearly defined:
The input is a payload with the
The output is a payload with the added property
coordinateswhich is an object containing latitude and longitude.
Your tests should focus as much as possible on testing these sorts of input-output scenarios. If anything goes wrong within that micro service, you’re going to find out very quickly by testing that the outputs are correct given certain inputs.
Sure, there may be all kinds of complex business logic operating inside your microservice. Unit tests can help checking the correctness of such logic.
But ultimately, there is only one type of test that matters: given an address, the service should return its geocoordinates. It’s what I call an “input/output” test. If this test passes, any business logic and 3rd-party APIs that are being used in the process must be correct.
Testing the function handler is the most effective way to do this.
With serverless functions, we are in this very useful position where all of our inputs and outputs have to pass through the function handler. There is, in other words, only one place where all the requests for that function will be received and responses will be generated. That place is the handler. This is ideal, and we should leverage it to our advantage.
Strategies to test the function handler include:
Using something like
axiosto hit the serverless local endpoint
Separating the content of the handler into its own function that can be invoked on its own by passing (mocking) its dependencies
Writing a test that simply calls the handler as is (no mocks)
Options #1 and #2 have their merits, but #3 is my favourite. It allows you to write a test that simply invokes your handler and checks out its response. It is easy to setup, and it tests the real thing (provided you’re connected to your cloud environment).
Testing that output B is returned given input A is all you need to know to be confident about your serverless function
Your function’s handler is the place where all the inputs come in and all the outputs are generated
To get the most out of your testing efforts, focus your handler tests first (preferably without mocks)