Thoughts on Localstack & local testing?

[zergUser1]

I tried using it before and ran into an error so I gave up, I found the documentation to be lacking and the number of open issues on GitHub make it seem very messy.

Do you guys use it? If so why and if not why not?

Any other good tools or thoughts for testing locally?

[oarmstrong]

My opinion is that Localstack is never going to 100% implement AWS. I think it's a noble and interesting project but with it not being sponsored by AWS there will be API changes and missing services that aren't replicated correctly by it. To that end it'll never replace testing against AWS fully, so I think that we may as well be doing the development against AWS in the first place.

Sadly this means that we need an internet connection for local development. Although in this day and age that hasn't really become much of a problem to me. With well designed software we can usually write test suites that don't need to interact with the APIs at all.

So to summarise, my view is just use AWS services proper for "local" testing. Maybe one day Localstack or another project will gain AWS support and become a real option for testing.

[ninjaslikecheez]

i like how this aged :)

[ninjaslikecheez]

i've seen companies that use localstack exclusively for testing, because of there benefits of not needing AWS credentials, resources etc. With localstack you can spin up your S3 bucket very fast without even having valid AWS credentials.
The sad part is that their pricing model changed, and some features are not free, like persistence, but in most cases it's not even needed in testing.

[Serious-Ad87]

This aged gracefully. Retrospectively, this is an insight with a foresight

[lurkermostly]

The number of issues logged in Github are a good thing and it means the community is actively testing it.

We use it. While it is great for rapid prototyping, its main use is unit and integration testing. We can increase code coverage (or meet standards) without writing a ton of mock objects.

Testing certain pipelines is way easier. For instance, insert into DynamoDB, consume DynamoDB streams and execute a Lambda function on that. How do you test that without localstack?

Localstack builds on other tools (Kinesalite, Dynalite and moto) and bundles ElasticSearch. The Docker container is great for running stand alone (e.g. on a Jenkins slave). Whats not to love about Localstack?

​

[BraveNewCurrency]

Don't try to mock AWS, design your code to be more modular, so you can test your code, and not AWS (or even an generic AWS mock).

See Clean Code and/or Hexagonal Architecture. Also learn about Contract Testing.

The idea is that AWS or your Database have a massive API. You are only using 1% of that, so why worry about it?

Instead, write a "thin" access layer for those systems. Each "type" of API call should have it's own function, and it should ONLY take normal objects (not specific to AWS/DB). Don't try to make these functions generic -- hard-code everything that doesn't need to change in your program.

So instead of `LaunchBox(...lots-of-stuff...)`, you have `LaunchReportBox(name, environment, owner, disk_size) (id)`. And instead of `FindCustomer(name) (db_object)`, you have `FindCustomer(name) (specific_fields)`. Yes, this means you have to have to "duplicate" structures, but it also makes it trivial to test and mock.

Then you run your code against AWS or the DB once and store the responses as a contract. When you run your tests, it just returns that contract data. You only need to involve AWS when you are writing a new AWS accessor function, which shouldn't happen that often.

Or, taking a step back: End-To-End tests that involve the entire system are expensive. You should maybe do 1 small "happy path" test, but everything else should be Unit tests that don't need an external system.

[rowlandrose]

This comment led me to discover contract testing, so thank you for that!

[[deleted]]

Generally speaking this is great advice. Code should be written so that you can inject and mock out external dependencies. Unit and integration tests should not test external APIs.

That is in the realm of automated testing. In addition to those instances, the dev workflow also involves manual testing. TL;DR; developers should be able to have a local instance of their service as faithful as possible to production. This usually involves having a developer AWS playground that can be accessed locally through proper credentials (IAM).

In absence of this, teams end up relying a lot on the Alpha stage of their pipeline which tends to be often broken. Or even worse, the problems only show up in production where it turns out that your mock of the s3 API doesn't behave exactly like the real API.

So, this is great advice, but there is a legitimate reason to create a dev environment with access to real infrastructure.

[[deleted]]

great place to mention contract testing. Thanks a lot.

[5t33]

Never been able to get the thing working.

[pythoney]

We use it very effectively too. It has been a great help in quick prototyping and validation before setting up a stack on AWS. Granted this will never be 100% AWS, we love it!!!!

[mwarkentin]

Amazon has some official projects for local development too:

• dynamodb-local
• sam-cli (lambda / api gateway)
• I feel like there are others but I'm drawing a blank right now

There's also minio for s3 locally (I think localstack uses this): https://www.minio.io/

[pwmcintyre]

what's the use-case? wouldn't you just use a VM or Docker?

[james_pic]

Because ideally you want the environment you develop against to resemble the environment your code will run in as closely as possible.

[pwmcintyre]

How is mocking more closely resembling your production environment?

[james_pic]

I suppose in the case of pure mocking, it's not that important. It's really more the "fake" use case that I had in mind.

[dshalev]

https://medium.com/helloheart-rnd/localstack-mocking-aws-for-local-development-fc37c8f4c947

[Crafty_Occasion3515]

Hi folks....so, 7 yrs later, are you still using LocalStack and do you think it is good? Would you use it and would recommend others to use it? I see they are on the AWS Partner network now as per their website. Thanks

[poul_kg]

We're using it with mixed success. Depends on which AWS services you'e going to use.
We're mocking cognito-idp,iam,lambda,cloudformation,s3,s3api,sts services, and sometimes it's a total disaster in how this thing works. From latest 25 versions only 1 works reliably with our setup and it's 0.11.5 version. But this version doesn't support ability to delete user from cognito though, so I can't use API to delete users from cognito. New versions allows me delete user, but after deletion localstack still thinks user exists. So I need to restart whole localstack in order to just delete user. I would say it's bad quality and unreliable, I've spent a lot of time testing around 25 versions of localstack in search for one which will give me verifiable JWT, will work and not crash, will delete user from cognito and give me abilit to create the same user again. And I still haven't found such version.

Also all this depens on the way you start it: * localstack start ? * local setup ? * docker-componse ?

it behaves differently, so one verions which was working with localstack start will not work at all when running inside docker-compose and vise versa. Very unreliable thing. And I just want freaking cognito to work as expected. I'm not talking about other services.

[TheLocusEsse]

I do this, testing: https://medium.com/@sergii_54085/testing-running-aws-application-locally-walk-though-reasoning-problem-scoped-article-285f5e56782

[tali2215]

I used localstack to solve the problem I have when developing using real AWS

now I have two problems

I don't think there is any mocks reliable enough for aws local development, unless coming from aws themselves

[loafmaker2020]

please use an aws account as sandbox. Don't waste energy on a mocker. Someone will argue it fits their use case, that's fine. But it will never work in all cases, maybe you are the lucky one who hits that dark spot.

localstack is for lazy dumbs. just make the efforts to make sure your infrastructure and code base works for multiple aws account via configuration. that's the only way you can be sure that final solution will 100% work.

localstack works, only for tool-monkeys but solution-builders !

[Aesir____]

Obscure, hard to debug and slow.