Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I kinda like most of these emulators but why is there none targeting GCP/Azure
  • Interesting thing, looking forward to testing it with my Smithy-generated Python AWS SDK https://github.com/kap-sh/capo
  • But how does it compare to floci, which already picked up with localstack left off?
  • 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.
  • "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 so many of these, but none of them simulate the surprise-billing experience.
  • 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’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.)

Explore Birbla archives

Fakecloud: Local AWS cloud emulator for integration tests · Birbla