Integration tests suite for provisionedConcurrency

[pgrzesik]

I took the liberty of moving the conversation about integration tests for provisionedConcurrency from the discussion in this PR: #8298 (comment)

Use case description

The goal here is to provide coverage of provisionedConcurrency in our integration test suite.

Proposed solution

Solution based on the comment from @medikoo

In light of that, yes I totally agree it's worth to have some deployment that tests provisionedConcurrency setup. It'll probably be optimal to have one dedicated stack (test), for testing all provisioned concurrency cases (but we can start just with this one). What do you think?

• Introduce a test/integration/provisionedConcurrency.test.js test that will cover all provisionedConcurrency based cases, starting with just one for sqs.
• Introduce a test/fixtures/provisionedConcurrency fixture which will have a single serverless.yml configuration with all needed functions (starting with just one for sqs)

Before starting the implementation, I would like to resolve if the above sound like a reasonable approach, thanks in advance 🙇

[medikoo]

Thanks @pgrzesik for opening that. Let me know if you have other suggestions or findings

[pgrzesik]

I think that the approach you suggested originally should work quite well. The only other approach that came to my mind is to keep provisionedConcurrency tests in the same suite as tests for specific event, e.g. for sqs, to keep the test in sqs.test.js and use sqs fixture with an additional function that uses provisionedConcurrency.

Which approach is better in your opinion?

[medikoo]

Which approach is better in your opinion?

I think keeping it in one place, will allow us to rely on single provisioned lambda, and that I think will be more performant (and will incur less costs). It's the only reason I called for that.

[pgrzesik]

Thanks for the clarification on that topic. Just to clarify the last thing - if I understand it correctly, we will start out with a single function with sqs event and if we ever need to test e.g. sns with provisionedConcurrency, the function will also handle sns event and will be able to appropriately process both of them and so on for further scenarios?

Originally I thought that each new event will get a separate function but that also makes a ton of sense from efficiency/costs perspective 👍

[medikoo]

the function will also handle sns event and will be able to appropriately process both of them and so on for further scenarios?

Hopefully that could be the case, but if for some reason it'll be a no go, we'd need to introduce an other function

[pgrzesik]

Perfect, thanks a ton, I'll be happy to pick up this one if that's okay 👍

[medikoo]

That'll be great @pgrzesik ! Thanks for being a part of the community and your work on improving the Serverless Framework!

[pgrzesik]

Thanks for the kind words @medikoo, I'm happy that I can help and contribute at least a little bit 🙇