Write your tests once and run them twice - as both unit and integration tests - sounds like a good deal, let's take a look at this practice.
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.