Fakecloud: Local AWS cloud emulator for integration tests

There’s also MiniStack, which forked from LocalStack after they started breaking developer workflows: https://ministack.org/

Both fakecloud and its website look sloppily vibe-coded, and its “authors” are anonymous. It’s going to take a while for it to earn trust. I’d treat it with suspicion. (Curl-to-shell pipe to install? Ugh.)

Instead of a simulator that runs in its own process, I would recommend mocking out inline in the tests. Only then are your tests entirely “self contained”.

Otherwise your test implicitly make assumptions like “User A is always off-line” (or bucket A is always empty), add a reader of the test would have to go find where that assumption is hardcoded in the simulator and verify it separately from the test itself.

To someone reading that test it is not intuitive that user A is always off-line or bucket A is empty.

If you mock out in line, you can have tests that mock user a / bucket a — to simulate any state for any user or bucket. Perhaps multiple states in one test.

Also think about scenarios like the bucket is initially populated, but then on a subsequent request, it’s empty.

With the simulator approach, you’d have an endless number of permutations of scenarios to add — each of these scenarios would be highly coupled to the test it belongs to, so why not just put it in line in the test itself?

Any reader of the test that uses inline mocking would clearly see which scenario is being tested instead of having to dive into a separate simulator to see what special treatment is hardcoded for User a / bucket a (or maintaining potentially hundreds or thousands of simulated buckets with ad hoc names like “empty-on-second-request” or “bucket–that-responds-slow-and-times-out-but-succeeds-on-retry”.

There are so many of these, but none of them simulate the surprise-billing experience.

"46 at true 100% conformance". This is factually incorrect. Inspected their DynamoDB service and it comes nowhere close to implementing the full api.

There are always nice, but there are a lot of scaffolding work involved with larger systems. It would be nice to be able to provide for example the terraform of the infrastructure and let these tool create their own. Might be a nice feature to add because I haven't seen it done yet.

But how does it compare to floci, which already picked up with localstack left off?

Interesting thing, looking forward to testing it with my Smithy-generated Python AWS SDK https://github.com/kap-sh/capo

I kinda like most of these emulators but why is there none targeting GCP/Azure

Why not just offer an AWS compatible cloud service at this point ... can you copyright an API?

The support for SES looks really great, better than LocalStack.

- https://fakecloud.dev/docs/services/ses/

There is also localemu, which I understand to be another localstack fork: https://localemu.cloud/

Local stubs like this are a lifesaver for one-person webhook testing without burning cloud credits every morning.

I always welcome warmly projects like these, the only problem is that unless there’s a strong community behind, founders tend to build companies around them, raise capital, then put useful functionalities behind paywalls (see localstack).

When I see that, it always reminds me of Steve Jobs’s quote: ”It’s not a product, it’s a feature”.

Aren’t cloud companies like AWS, Azure, GCP the first to be interested in providing their users a meaningful way to do test integrations of their products? Shouldn’t they provide them in the first place?

Alot of mock services have come out of the woodwork now due to genAI, but I don't think these are the solution from decoupling your services from cloud providers, because they have to keep up with schema updates for every single service which isn't practical even with genAI.

You should be writing everything in a sans-IO pattern: define your core, the interfaces, and your own types, (even if it seems redundant) and never, ever import a single dependency from a cloud provider in that core. Make two implementations of the interfaces: one in-memory that can be spun up quickly for testing and one that uses the actual cloud provider APIs. Now instead of hoping fakecloud or localstack update their mocks to be inline with AWS, all you have to do is update your dependencies and the implementation code and the core can be left alone for a long time.

This is also why I avoid lambda and other "serverless" compute like the plague because it's designed from the ground up to lock you in.

These miss the point of integration testing (in my Humble opinion). Integration tests are valuable because they get around the problem of mocking. They let you reach out into the foreign thing you use and see if it behaves the way you expect it to. If you replace the real thing with a fake thing, you are, well, by definition, not learning anything about the real thing. It's the subtle behaviors and quirks of real services that often cause the most problems. (It's why testing the DDB Local often hides the painful eventual consistency problems you see with DDB proper.)

My $0.02: just use the AWS SDK to spin up real infrastructure on demand. You can provision SQS in < 10ms. Buckets in <100ms. DDB can take upwards of 30 seconds to a minute if you're adding GSIs, but it's a very small tax in exchange for the confidence it brings. (People often balk at this idea when they first hear it, but give it a shot! I have stamped out many a bug thanks to being able to bounce ideas off real infra.)