So I've been exploring using the automation API with some automated integration tests with dynamodb-local (localstack in future). - For isolation reasons each test uses it's own stack and thus infra resources. This facilitates running tests in parallel. - Using a single shared LocalWorkspace across tests. - Using local backend (setting backend url to

file://~

) - A stack with a single resource, a simple dynamodb table. - So everything is local and should not be making any external network calls. Non-scientific performance numbers: -

WorkspaceStack.CreateOrSelectAsync

~ 1.4s -

WorkspaceStack.SetConfigAsync

~ 0.7s -

WorkspaceStack.UpAsync

~ 6.5s Overall each test has ~9s overhead. Not bad to be honest but it'll add up as the test count increases. If I use the AWSSDK directly to deploy a table it is significantly faster (<1s). However with this approach I'd have to maintain some sort of table definition abstraction that would be used both in the test fixtures and pulumi component to achieve alignment / re-use. This would add a complexity cost. Thought I'd mention the above in the hope that there could be some performance improvements made to the Automation API. In any case, it's really nice stuff :)

That's awesome. I've never used any of the local fakes for testing, it's on my backlog. Do you have anything sharable yet? The localstack implementation in particular is very interesting.

Hope to have something sharable in the coming week. Component I'm working on is dynamodb only so just using dynamodb-local at the moment. Will be getting to localstack shortly after.

This is awesome, thanks for the feedback. Just confirming, you’re using the dotnet SDK here? EDIT: Yes you are! You’re the one whose questions I answered in the issue yesterday 🙂

nice one @fresh-summer-65887! I hope there's a blog post coming here? 🙂

I'm also very curious about integration testing targetting localstack, as that was something we were going to explore before long