I use the S3, SQS and SNS extensions all the time. Absolutely fantastic during development and testing, even for small scale staging deployments sometimes.
Wow, thanks for this wake-up call! I had checked localstack + Terraform combo some time ago and I don’t recall that option being there. Time to refresh my knowledge on this.
I started using Localstack and wanted to make it work, but found myself using a sandboxed AWS account more and more over time because there was less friction.
sigh, i vaguely remember when local stack was free, back when it was moto (library + rest support), and then atlassian doing the initial localstack, and then handing it over to the community. on the day after docker is done, i'm not sure there's much vc value add in the pure dev tools space, its feeding into a commodity with a motivated community, especially in this case given a cost incentive (per dev licensing) and higher fidelity alternative in using an actual test account.
fwiw, I tried local stack a while ago, and quickly realized that features and edge cases where not really where it worked. it hits the 80/20 rule of apis and a 20/80 rule on error conditions. I switched out to flight recording on the apis to get better coverage and tracking to new features and more customizable err injection.
It's amazing to me that a video like this is apparently sanctioned by two large companies, and yet the use of terminology is so very divergent from the norm.
The thing you're calling "stubbing" (a usually local, working implementation of a subset of a service's functionality) is usually called using fakes. You describe Moto as a "stubbing" library, but it's neither a stubbing library nor a fake... it describes itself as a mocking library, and that's exactly what it is. You describe localstack as a stubbing library that combines "best of breed stubs"... but it's actually a collection of fakes built up from simpler fakes and mocks (their readme says "LocalStack builds on existing best-of-breed mocking/testing tools").
I don't know if you're purposefully using nonstandard terminology or if you're just mimicking how the terms are used inside Capital One, but since this video is educational, it seems irresponsible to diverge so far from industry-standard terms.
Note, I don't think it's very important which terms are chosen to mean which thing. But we need some consistency. The fact that you're disagreeing with the terminology that's used in the readmes of the tools you're talking about should be a clue.
Regardless of what Moto describes itself as, if you look at the code you'll realize its not a mock at all, its a fake per your definition. Given your concern with terminology, I'd suggest filing an issue there. Also given the divergence from your terminology in the ecosystem (Moto, localstack) for how tools describes themselves, perhaps its not the norm. To quote from your fowler article "The vocabulary for talking about this soon gets messy - all sorts of words are used: stub, mock, fake, dummy."
True that it gets messy. It seems like the word "mock" might be becoming a general term for what Fowler calls"test doubles". So be it.
But stubs and fakes are roughly on opposite sides of the spectrum. Stubs are as simple as can be (doing nothing more than providing logic-free preprogrammed responses), and fakes actually work. There very word "stub" connotes that it's not a full thing, certainly not a thing that works. A stub arm is a tiny piece of an arm. Most of the arm is missing.
If we're going to call a fake a mock, fine... but let's not call a fake a stub. We don't need more confusion.
Great video! Thanks for sharing. I have had a lot of trouble mocking my AWS calls. I’m going to give flight recording a try because I am already basically doing that in my mocks, but manually. It’s painful.
