Hey everyone! We blogged about our serverless developer experience which is built around ❤️ SST ❤️ . It won't be mind-blowing for most people in this community already working with SST, but we thought it would be nice to share our experience. Let me or @Matt Vagni know if you have any questions! https://journal.plain.com/posts/2022-02-08-a-magical-aws-serverless-developer-experience/

That's an excellent article @Akos I suspect more than a few people will be using that to help sell the idea of SST to management. I'm curious what your testEvents.expectEvents looks like? I assume you're hooking up temporary event listener to use to validate ?

Haha, @thdxr had the exact same question when I shared a preview with him before hand. I'll copy in my same answer: We have a setup that saves events in DynamoDB and the tests assert based on that. Slightly more complicated, but not that difficult to setup: 1. Conditionally in CDK, depending on the environment (where we run tests, i.e. not prod yet), create: a. A dynamodb table where pk is the workspace id (or whatever tenant id you have) sk is the event's timestamp (or in our case just the id since we use ulid). We also have an expiry timestamp to not store these test events forever. b. A lambda (non sst / live reload) that receives an event and writes out the event to the dynamodb table. This relies on our events having a standard event envelope structure and being able to determine the workspace id + the event id without knowing every possible payload. c. Add a catch-all rule to each eventbridge eventbus that routes all events on the bus to the event writer lambda 2. Then in our tests we just do a query for all events in the pk (and get a sorted array as they were received). This is done in an eventually block, i.e. keeps retrying until the expect passes or it times out. Since it picks up ALL events in a workspace, we have quite a few helpers to make sure we're expecting on the things that matter for that specific test, like: a. expectEvents: strict match b. expectSomeEvents: array containing match c. expectSomeEventsExcept: strict match excluding some event types d. expectNoEvents: wait for N seconds and expect 0 elements e. expectAnyEvents: any event just passes this All in all, this works quite well. The sad thing is that eventbridge is slow, i.e. best case it's like 400-500ms worst case we've seen delays up to a 2-5 seconds.

Very interesting, thank. you 🤔

Thank you for this. Testing part was very helpful. Been looking for inspirations/guides on how to do integration tests in our serverless app.

Yeah seriously this is a really good post. Shared it all over our Twitter. Also that video at the end with the SST Console in action looks next gen 😂

Reading.... spotted this correction:

s/tangible any benefit/any tangible benefit/

Ahhh, there always needs to be a typo... fixed it! Thanks. And yeah, the post ended up focusing alot on testing since SST just works ™️ and there's not much else to say about it 😄 We'll definitely do a follow-up where we deep dive into the details of our test setup. There's a lot we didn't mention, especially on how to best manage state as well as how to structure your code so the tests still run quickly and aren't flaky.