I actually feel a little bit of rage whenever I see it being used in a project. People think they’re Integration testing AWS, but they’re really testing the mo

I actually feel a little bit of rage whenever I see it being used in a project. People think they’re Integration testing AWS, but they’re really testing the mocking behaviour of Moto over a loopback interface. But all they’re doing is making their test pipeline bloody slow and memory hungry. What people need to understand about testing against AWS is that the SDKs provides the typing guarantee. So it’s nearly impossible to make an invalid call with any AWS SDK. Moreover, doing a test along the lines of ‘post to S3, then get the object to verify it has been posted’ is pointless too. Because that’s not how AWS works. In a real application, you don’t have any guarantees the object exists in S3 immediately afterwards, just a high probability that it will become consistent relatively quickly. If you do such a thing in a real world environment, you’re liable to have intermittent failures. The eventually consistent behaviour is more obvious with other APIs like the EC2 interface, where no one expects an instance to be created immediately. There are a few exceptions to this rule, but they’re not accurately modelled by localstack. What people need to test when developing AWS applications is that there _was_ a call to an AWS API, not that the AWS API behaved with all of its documented side effects. You can’t unit test the black box of AWS, you have to QA it as part of an application release.