After some time of developing serverless systems (especially on AWS) I take a look back and try to summarize what I have learned so far.
Black-box testing is testing of a component via its API without any knowledge of its implementation details. As the opposite there is the white-box testing. And it about testing implementation, right? Well, no...
Nothing new, but I keep seeing this bad practice around again and again... Let's explain why this is incorrect:
Software architecting is about tradeoffs. Even when the theory is good the implementation details can break it. In this article I try to find the best from two architectural approaches: Package by component and Clean architecture (a variety of Ports and adapters).
Why shouldn't we test the implemetation? How to decouple our tests from the code? What is the reason to add a new test? Why is mocking a code smell? In this article I will try to find answers to those questions.
Talking about serverless microservices, functions are the basic building blocks of the service functionality. How to design them from the code and deployment perspektive?
Designing a system architecture is always about making tradeoffs. Microservices resp. serverless architecture has a lot of benefits, but some drawbacks as well. One of them is testing. Testing serverless systems is hard. In this article I will discuss some practices which work for my project.
Based on my question on StackOverflow I did a bit investigation about how (likely) are Node.js functions called in AWS Lambda containers.
In my previous article I showed how to build a simple RESTful microservice. For sake of simplicity I skipped some good practices for building REST APIs and I feel a bit guilty about that. I think that topic deserves its own article. And here we go... we take a look at the previous API and try to do things better.