Serverless architecture uses a lot of servicesâ€Šâ€”â€Šhence why some prefer to call the architecture â€œservice-fullâ€ instead of serverless. Those services are essentially elements of an application that are independent of your testing regime.
An external element.
A good external service will be tested for you. And thatâ€™s really important. Because you shouldnâ€™t have to test the service itself. You only really need to test the effect of your interaction with it.
Hereâ€™s an example â€¦
Letâ€™s say you have a Function as a Service (e.g. Lambda function) and you utilise a database service (e.g. DynamoDB). Youâ€™ll want to test the interaction with the database service from the function to ensure your data is saved/read correctly, and that your function can deal with the responses from the service.
Now, the above scenario is relatively easy because you can utilise DynamoDB from your local machine, and run unit tests to check the values stored in the database. But have you spotted something with this scenario? Itâ€™s not the live serviceâ€Šâ€”â€Šitâ€™s a copy of it. But the API is the same. So, as long as the API doesnâ€™t change weâ€™re ok, right?
To be honest, Iâ€™ve reached a point where Iâ€™m realising that if we use an AWS service, the likelihood is that AWS have done a much better job of testing it than I have. So we mock the majority of our interactions with AWS (and other) services in unit tests. This makes it relatively simple to develop a function of logic and unit test itâ€Šâ€”â€Šwith mocks for services required.