TL;DR notes from articles I read today.
How to test serverless apps
- Most of what goes wrong in serverless architecture lie in the configuration of functions: event sources, timeouts, memory, IAM permissions, etc. With functions being stateless, the number of integration points also increases, so you need more integration tests than unit or end-to-end testing.
- The first stage of testing should be local tests, for which you can: run the Node.js function inside a wrapper. Invoke functions locally using tools such as Serverless framework or AWS SAM local. Use docker-lambda to simulate an AWS Lambda environment locally. Use local-stack to simulate AWS services locally. However, none of these simulate IAM permissions or API authentication.
- The second stage is unit tests. If you have a complex piece of business logic, you should encapsulate it into a module and test it as a unit.
- Use integration testing to test code against external services you depend on, such as DynamoDB or S3. Run these tests against real DynamoDB tables or S3 buckets, and not mocks and stubs. Keep the same assumptions as of the code.
- Once the local tests have checked your code, move to acceptance testing: whether functions have the right permissions, timeout settings, memory, API Gateway event sourcing, etc. Do this after deploying.
- Finally, if your serverless application is used by a UI client directly or indirectly, make sure your changes are compatible with the client - you can have a QA team test this manually or use an automated test framework
- Once deployed, you should still use robust monitoring and error reporting tools for issues developing in production.
Full post here, 6 mins read
What is legacy code? Is it code without tests?
- The definition of legacy code as code without tests comes from Michael Feathers’ Working Effectively with Legacy Code.
- An alternative definition is valuable code that is difficult to change (you are afraid you might break existing behavior) because you struggle to understand it.
- You overestimate the complexity of unfamiliar code or code you don’t remember why you wrote. Sometimes it gets better after working with it a few months.
- Having tests is not enough, good tests make you confident about changing unfamiliar code but poor tests don’t.
- A recipe for legacy code is multiple people working on a codebase, over a long period, with conflicting requirements, under time pressure. This happens because knowledge is always imperfect and you take shortcuts to meet deadlines until every move introduces a bug and new features take ages to implement.
- Finally, ‘legacy code’ is a matter of personal perspective: it depends on your understanding of the code and your feelings about changing it.
Full post here, 4 mins read
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Top comments (0)