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.)
The blog posts are all attributed to "Lucas Vieira" and the dev group https://faisca.dev that is attributed as the author has 2 other projects. Lucas comes up in LinkedIn and looks like an actual person working in San Francisco.
Because taste, creativity, and differentiation matter to a human audience. Perhaps not you personally, but to most people. Ask any experienced marketer.
It’s not really a question of whether they’re using it or not (most of them are); it’s a question of whether they’re using it to generate work product intended to be consumed by their customers. Most know better than that. Some might use it for that, too; but you know what they say about half of the population being below average.
For a mock server? Surely a versioned, standalone executable, library/package or docker image makes more sense. Integration tests generally need to be portable and running on CI, you don't wanna be shell-piping whatever exists in the moment.
The problem, for me, is that self-running installers can create a mess that's hard to keep track of.
I've run Linux without meaningful package management, as that was kind of the style of the time 30 years ago with Slackware. It can quickly become untenable.
There's no real difference between an uninspected script that gets piped straight from the URL into the shell, or a similarly-uninspected make&&sudo make install routine from a tarball. They can both execute code that does bad things (whether unintentionally or deliberately), and they can both leave a mess that is hard to cleaned up.
I've found that it is better to just avoid going down that road to begin with. Whether distro-specific packages, Docker containers, flatpaks, or whatever: All of these make housekeeping easier.
> The problem, for me, is that self-running installers can create a mess that's hard to keep track of.
For reasons my machine with a beefy GPU is stuck on an older set of Nvidia drivers. I've got them pinned with apt. The ollama installer fucked everything up by updating stuff that apparently wasn't pinned. After I had fun cleaning up that fucking mess I found it overwrote my custom systemd service file so I had to go in and fix that.
Curl-to-shell is a bullshit antipattern. I have no interest in going back to the dark days of expanding tarballs to / and hoping for the best.
And when the new distro-provided nVidia driver does something garish like, say, break XFCE, then it's easy(ish) to roll it back using distro tools and pin it there. After that, just wait until some other more-functional combination of shakes loose in the distro channel.
When a new nVidia driver shows up that promises a fix but the distro hasn't packaged it yet, then the temptation to just download and run the installer that's on nVidia's website. But using nVidia's special-sauce installer taints the system in ways that distro tools deliberately seek to avoid.
And: Oh, man. I'd almost forgotten about the binary tarballs that were intended to be simply dumped into /, where they'd just tromp on whatever. Sure, it was fast. And for some people, some times, it even worked. Sometimes, it didn't work. Other times, it broke other things that had been working. And it left a mess behind every single time.
A little bit of a mess isn't necessarily devastating on a personal system. But the mess accumulates every time such an unmanaged installation process happens until it eventually overwhelms to the point that even the most functionally-disorganized of people become dysfunctional.
If you're about to install an upstream binary with this and you're not reviewing this then it's purely (irrational) vibes to be concerned with the also unreviewed shell script from the same source.
Yeah but at least with a binary you can verify the checksum of a recent official immutable github release rathrr than just trust a script hosted on the website.
If you don't really trust the author, what's a checksum going to provide you? That the maybe malicious code released on GH has not been tampered with? Not so helpful.
In the case I described you are trusting the developer at least a bit. But you aren't trusting them to keep their website secure.
Furthermore, you can be sure that theversion that you download is the same version it has always been and it is the same version everyone else sees. Curl|bash can mean getting a version of the code that is different from everybody else.
It’s a shell script. You can download and read it before you run it. Piping it directly to the shell is reckless.
I’m not sure how your machine is configured but mine has permission boundaries and security policies that make sure programs are behaving properly. I don’t run everything with my personal user context.
curl-to-shell is a terrible installation mechanism because it's not easily reversible and I can't tell if any of the assets are signed, or integrity checked, or not.
Yes, the prompt was: "Make a Ministack website. Make no mistakes" Does that make it less useful?
You can check who’s using Ministack on public GitHub repos, NVIDIA, Block, NASA, the U.S. gov, the UK gov, and many others. There are plenty of examples demonstrating that we’re doing something good
If you still want to use COBOL because it makes you feel better or smarter, good for you. That doesn’t mean Ministack lacks quality
Your software can be great and your website can be mid at the same time. Perhaps the latter isn’t the highest priority for you, but criticism of it isn’t invalid.
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”.
That's fine if the interaction with the service is within the scope of your code. If you want to, say, mock out terraforming a bunch of IAM permissions to least-privilege a lambda such that you can check it actually works, you don't have a seam where any app-level tests can go in.
That's where the difficulty is, where the round trip to testing this stuff on live services is painfully slow and error feedback is mixed at best.
Here are some bugs:
- `ADD m.a.c :inc` update expression wrote a literal top-level m.a.c attribute but didn't change the nested number.
- TransactGetItems returned fields not requested.
- update expression can update the same key multiple times.
In total my conformance suite found 583 failures out of 1279 tests.
Thank you. I'm going through the DynamoDB issues now, starting with the three you listed. The Parity Suite is great. I'm wiring it into fakecloud's CI.
Funny fact, DynamoDB local fails about 100 of my conformance tests. Mainly around error message formatting and text. Just be careful about parsing those.
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.
AWS is still way ahead in cloud usage, that's probably why AWS is the primary target. Anyway, floci has GCP and Azure versions, how mature they are, I'm unsure. But it does exist.
I'm launching something in that space this week - if you're interested in trying one of those out, feel free drop me a message via my website (in bio) :)
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?
It depends on the company. Azure provides local emulators for some of their products like CosmosDB and Azure Storage.
Depending on what your size and other things, sometimes it's just easier to have dev instances you test against. Like S3 emulator, you could download one of many and test it but unless your test suite is extensive, the costs against S3 test bucket would probably cost you .03 cents for assurances that everything will work against AWS. If that's breaking the bank at the company, you probably have bigger problems.
> Like S3 emulator, you could download one of many and test it but unless your test suite is extensive, the costs against S3 test bucket would probably cost you .03 cents
Not sure if your serious.
You picked the simplest service that isn't expensive at all to run. Have you tried with an RDS cluster for example, how does that work?
Does your integration test create a new cluster to use? That's slow to set up.
Does it use an existing one? Now you might have failures due to noisy neighbors and your cost will not be small.
And that's just RDS, as soon as it's not serverless, costs aren't trivial anymore.
I assume for RDS for integration testing, you could just use publicly available software. So stand up MySQL container if your RDS is MySQL. This is integration testing, not load testing so shared RDS in lowers would be fine as well. Noisy neighbors shouldn't be a big deal.
Again, while local cloud emulator is great for cost sensitive customers, at some point, you should test Dev against almost exact environment you will be running Prod on. If not, you are asking for eventual outage in Prod when some slightly different AWS thing bites you.
It depends on your tests and environments. MySQL container should be used for integration and CI/CD testing if you are cost sensitive. Dev or Staging should be end to end testing against AWS RDS.
Whole point is this stuff is for those who think running Dev RDS is too expensive.
You’d think that but it doesn’t seem to be the case. I do a lot of offline development and the only way it used to be possible was localstack but that’s AWS only. The open source community is the only interested party, it seems. Thankfully, there’s a lot of contribution happening in this space. Because I have need, I make a lot of my own contributions. I’m doing full stack cloud development against GCP without ever leaving my device.
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.
doesn't it boil down to not using unique services?
If nobody provides an alternative today that could switch as quickly as changing an endpoint and token then you are coupled.
It's not a technical decision as much admitting in the strategy that we are cutting corners because it's cheaper/faster today but some hypothetical day in the future when we'll magically have more resource we won't?
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.)
Cleanup is indeed an art when you go with this approach. Namespacing helps a lot, as well as little things like randomizing individual queue names such that test run B never knows that infra from run A (that may still be hanging around from a failed cleanup) exists.
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.)
Happy living with Moto https://docs.getmoto.org/en/latest/index.html
> and its “authors” are anonymous.
The blog posts are all attributed to "Lucas Vieira" and the dev group https://faisca.dev that is attributed as the author has 2 other projects. Lucas comes up in LinkedIn and looks like an actual person working in San Francisco.
Re: curl; this seems to work:
faisca.dev is also vibed - perhaps it's a real human using AI to build an online fascade
I don't think it's being questioned that at some point there is human behind this. Though it could always be that spider.
why does it matter that it's a vibe coded website?
Because taste, creativity, and differentiation matter to a human audience. Perhaps not you personally, but to most people. Ask any experienced marketer.
I don't know about your experienced marketers, but mine are all using AI in some way shape or form!
It’s not really a question of whether they’re using it or not (most of them are); it’s a question of whether they’re using it to generate work product intended to be consumed by their customers. Most know better than that. Some might use it for that, too; but you know what they say about half of the population being below average.
Agreed with everything up to:
"curl-to-shell pipe to install" - what's the problem here? that's pretty common on linux systems and something the AWS CLI uses.
Or is the problem the fact that this dev is untrusted and is executing a possibly malicious script on your machine?
For a mock server? Surely a versioned, standalone executable, library/package or docker image makes more sense. Integration tests generally need to be portable and running on CI, you don't wanna be shell-piping whatever exists in the moment.
The problem, for me, is that self-running installers can create a mess that's hard to keep track of.
I've run Linux without meaningful package management, as that was kind of the style of the time 30 years ago with Slackware. It can quickly become untenable.
There's no real difference between an uninspected script that gets piped straight from the URL into the shell, or a similarly-uninspected make&&sudo make install routine from a tarball. They can both execute code that does bad things (whether unintentionally or deliberately), and they can both leave a mess that is hard to cleaned up.
I've found that it is better to just avoid going down that road to begin with. Whether distro-specific packages, Docker containers, flatpaks, or whatever: All of these make housekeeping easier.
> The problem, for me, is that self-running installers can create a mess that's hard to keep track of.
For reasons my machine with a beefy GPU is stuck on an older set of Nvidia drivers. I've got them pinned with apt. The ollama installer fucked everything up by updating stuff that apparently wasn't pinned. After I had fun cleaning up that fucking mess I found it overwrote my custom systemd service file so I had to go in and fix that.
Curl-to-shell is a bullshit antipattern. I have no interest in going back to the dark days of expanding tarballs to / and hoping for the best.
Right. I've done the same.
And when the new distro-provided nVidia driver does something garish like, say, break XFCE, then it's easy(ish) to roll it back using distro tools and pin it there. After that, just wait until some other more-functional combination of shakes loose in the distro channel.
When a new nVidia driver shows up that promises a fix but the distro hasn't packaged it yet, then the temptation to just download and run the installer that's on nVidia's website. But using nVidia's special-sauce installer taints the system in ways that distro tools deliberately seek to avoid.
And: Oh, man. I'd almost forgotten about the binary tarballs that were intended to be simply dumped into /, where they'd just tromp on whatever. Sure, it was fast. And for some people, some times, it even worked. Sometimes, it didn't work. Other times, it broke other things that had been working. And it left a mess behind every single time.
A little bit of a mess isn't necessarily devastating on a personal system. But the mess accumulates every time such an unmanaged installation process happens until it eventually overwhelms to the point that even the most functionally-disorganized of people become dysfunctional.
Running arbitrary code directly in your terminal is very dangerous
If you're about to install an upstream binary with this and you're not reviewing this then it's purely (irrational) vibes to be concerned with the also unreviewed shell script from the same source.
Yeah but at least with a binary you can verify the checksum of a recent official immutable github release rathrr than just trust a script hosted on the website.
If you don't really trust the author, what's a checksum going to provide you? That the maybe malicious code released on GH has not been tampered with? Not so helpful.
In the case I described you are trusting the developer at least a bit. But you aren't trusting them to keep their website secure.
Furthermore, you can be sure that theversion that you download is the same version it has always been and it is the same version everyone else sees. Curl|bash can mean getting a version of the code that is different from everybody else.
Any code I didn't write is arbitrary code. At some point I'm left to trust someone or run no software at all.
It’s a shell script. You can download and read it before you run it. Piping it directly to the shell is reckless.
I’m not sure how your machine is configured but mine has permission boundaries and security policies that make sure programs are behaving properly. I don’t run everything with my personal user context.
Actually... Server can detect if you are piping or not and serve a modified version for inspection.
But really, there is no reason not to use prebuilt packages for distribution. Curlpiping needs to die.
At first I thought “this sounds like bullshit” but then found https://web.archive.org/web/20230408195648/https://www.idont...
Package distribution is the best solution but why would you download the install script a second time?
So then... Just do that and it's no longer reckless.
If someone wants to be reckless they can be. If someone doesn't, they also have that ability.
I'm worried that this behaviour has to be defended.
curl-to-shell is a terrible installation mechanism because it's not easily reversible and I can't tell if any of the assets are signed, or integrity checked, or not.
> Both fakecloud and its website look sloppily vibe-coded
As if the MiniStack website wasn't also obviously vibe-coded lol.
Yes, the prompt was: "Make a Ministack website. Make no mistakes" Does that make it less useful?
You can check who’s using Ministack on public GitHub repos, NVIDIA, Block, NASA, the U.S. gov, the UK gov, and many others. There are plenty of examples demonstrating that we’re doing something good
If you still want to use COBOL because it makes you feel better or smarter, good for you. That doesn’t mean Ministack lacks quality
Your software can be great and your website can be mid at the same time. Perhaps the latter isn’t the highest priority for you, but criticism of it isn’t invalid.
It probably is, and that’s not great, either.
[flagged]
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”.
That's fine if the interaction with the service is within the scope of your code. If you want to, say, mock out terraforming a bunch of IAM permissions to least-privilege a lambda such that you can check it actually works, you don't have a seam where any app-level tests can go in.
That's where the difficulty is, where the round trip to testing this stuff on live services is painfully slow and error feedback is mixed at best.
And if you want to see how they all interact together in AWS, that's why you have a development sandbox AWS account.
Better yet, use dependency injection and use fakes. Makes it very easy to test out logic
There are so many of these, but none of them simulate the surprise-billing experience.
File a feature request! ;)
"46 at true 100% conformance". This is factually incorrect. Inspected their DynamoDB service and it comes nowhere close to implementing the full api.
Here are some bugs: - `ADD m.a.c :inc` update expression wrote a literal top-level m.a.c attribute but didn't change the nested number. - TransactGetItems returned fields not requested. - update expression can update the same key multiple times.
In total my conformance suite found 583 failures out of 1279 tests.
Thank you. I'm going through the DynamoDB issues now, starting with the three you listed. The Parity Suite is great. I'm wiring it into fakecloud's CI.
Wow! This is not production-ready at all. DynamoDB would be my main use case. I'll stick with DynamoDB local.
Funny fact, DynamoDB local fails about 100 of my conformance tests. Mainly around error message formatting and text. Just be careful about parsing those.
https://paritysuite.org/ You can check this, awesome work they have to check ddb vs real (local ddb also has a lot of diff with real ddb)
Interesting - I've only ever used it for unit tests and the only issue I had was (unsurprisingly) restoring from a back-up not being supported.
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.
I use tf with floci and floci-gcp, weekly…
Oh nice, not aware of this. We're opentofu on GCP, so could be a good addition to ci
[dead]
But how does it compare to floci, which already picked up with localstack left off?
you mean floci? https://floci.io/floci/
Yeah. Stupid really didn’t want to type that. :)
Floci happened to be discussed yesterday, with 47 comments: https://news.ycombinator.com/item?id=49854416
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
AWS is still way ahead in cloud usage, that's probably why AWS is the primary target. Anyway, floci has GCP and Azure versions, how mature they are, I'm unsure. But it does exist.
Right. Floci got posted yesterday here on HN.
https://news.ycombinator.com/item?id=49854416
Hard to replicate all the bugs in azure.
Agreed. Azure would be nice. Something that can work with Terraform too.
Check out floci-az. I haven’t touched it but I know it’s there.
I'm launching something in that space this week - if you're interested in trying one of those out, feel free drop me a message via my website (in bio) :)
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?
It depends on the company. Azure provides local emulators for some of their products like CosmosDB and Azure Storage.
Depending on what your size and other things, sometimes it's just easier to have dev instances you test against. Like S3 emulator, you could download one of many and test it but unless your test suite is extensive, the costs against S3 test bucket would probably cost you .03 cents for assurances that everything will work against AWS. If that's breaking the bank at the company, you probably have bigger problems.
> Like S3 emulator, you could download one of many and test it but unless your test suite is extensive, the costs against S3 test bucket would probably cost you .03 cents
Not sure if your serious.
You picked the simplest service that isn't expensive at all to run. Have you tried with an RDS cluster for example, how does that work?
Does your integration test create a new cluster to use? That's slow to set up.
Does it use an existing one? Now you might have failures due to noisy neighbors and your cost will not be small.
And that's just RDS, as soon as it's not serverless, costs aren't trivial anymore.
I assume for RDS for integration testing, you could just use publicly available software. So stand up MySQL container if your RDS is MySQL. This is integration testing, not load testing so shared RDS in lowers would be fine as well. Noisy neighbors shouldn't be a big deal.
Again, while local cloud emulator is great for cost sensitive customers, at some point, you should test Dev against almost exact environment you will be running Prod on. If not, you are asking for eventual outage in Prod when some slightly different AWS thing bites you.
Your first paragraph "just use a MySQL container" and the second "test against what prod runs on", seem to contradict?
> If not, you are asking for eventual outage in Prod when some slightly different AWS thing bites you.
Exactly...
It depends on your tests and environments. MySQL container should be used for integration and CI/CD testing if you are cost sensitive. Dev or Staging should be end to end testing against AWS RDS.
Whole point is this stuff is for those who think running Dev RDS is too expensive.
You’d think that but it doesn’t seem to be the case. I do a lot of offline development and the only way it used to be possible was localstack but that’s AWS only. The open source community is the only interested party, it seems. Thankfully, there’s a lot of contribution happening in this space. Because I have need, I make a lot of my own contributions. I’m doing full stack cloud development against GCP without ever leaving my device.
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.
> decoupling your services from cloud providers
doesn't it boil down to not using unique services?
If nobody provides an alternative today that could switch as quickly as changing an endpoint and token then you are coupled.
It's not a technical decision as much admitting in the strategy that we are cutting corners because it's cheaper/faster today but some hypothetical day in the future when we'll magically have more resource we won't?
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.)
I think what actually pushes people back is cleanup not speed. Real infra can give you things you actually want to test.
Cleanup is indeed an art when you go with this approach. Namespacing helps a lot, as well as little things like randomizing individual queue names such that test run B never knows that infra from run A (that may still be hanging around from a failed cleanup) exists.
You seem to be mixing up integration tests with end to end tests.
[dead]
[dead]
[flagged]