At the AWS re:Invent 2022, our very own Pawel Zubkiewicz, Master Cloud Architect at TT PSC and AWS Serverless Hero, presented “Automated testing for serverless applications” during one of the Dev Chat sessions.
Pawel is a passionate expert on serverless since the very beginning of his cloud journey in 2016 and has been exploring the topic of serverless testing since the fall of 2020. During the Dev Chat Pawel shared his thoughts on the theory behind testing serverless applications in the cloud and using real AWS services of locally emulated resources.
Challenges with serverless
Testing serverless applications is challenging because testing itself has always been hard, even in the pre-cloud, monolith era. In serverless we can’t control every aspect of infrastructure, more over Lambda function code does not work without other AWS services, which makes writing tests challenging.
The evolution of testing approaches (source: link)
Read on for Pawel’s 6 key takeaways from his talk
1. Automate all tests. An ineffective development workflow can be replaced with automated tests. Tests are executed locally, but they use real cloud resources.
Why do you test:
- to have confidence that code works how we think it does
- to have a (fast) feedback loop after making a change in code
2. Don’t emulate AWS locally. Many serverless programmers complain about ineffective development flow. They write code, deploy to the cloud, invoke a Lambda function (it fails), check logs in Amazon CloudWatch, then start write code again. After several iterations like this, they finally have the working code, but that takes too long. Often, developers want to emulate cloud and test locally because they are after convenience and speed. Both can be achieved when testing using real cloud resources.
“Often I hear people SIMULATE the cloud because of convenience and speed, but both can be achieved when testing in the cloud.”
3. Use real cloud resources in tests. Instead of emulation of AWS on your local computer, you create resources in the cloud. For example, database (DynamoDB) and your integration test, executed locally connects to the DynamoDB in the cloud.
Why is emulation bad? Because it makes it hard to configure on local machine, and there is no warranty that it will work exactly the same as the real cloud.
4. Use an architecture style that facilitates test automation. Pawel’s favorite architecture style is hexagonal architecture, also known as ports and adapters, because it promotes the creation of loosely coupled application components and facilitates test automation. However, you may use any style you prefer as long as it makes testing easier.
5. Test Lambda privileges (IAM roles). In order to achieve the principle of least privilege, Pawel recommends writing tests that validate IAM roles. These tests are very similar to an integration test but use Lambda’s IAM Role to interact with AWS cloud; that way we may verify if it has correct privileges granted (in both ways, not too little, not too much. More importantly, on the screen there is a test that checks if a function is denied access to writing data – so a “negative” test)
6. Ease of use over internal complexity. Testing practice needs to be simple to use even for juniors. This doesn’t mean it was easy to define and build (it wasn’t). If it’s easy to write new tests people will do it, and benefits for the whole project/team/company outweigh the cost/time invested in building more complex structure/system underneath that enables it.
Pawel’s hope and conviction is wider adoption of serverless architecture. As serverless matures so do the practices around it as well. Years ago testing was problematic, and people used “testing issue” as an argument against using serverless. Today, severless no longer has the same testing issues.
Learn more about TTPSC’s cloud services: link