Maintenance: Refactor Feature Flags

[heitorlessa]

Summary

Stream of consciousness tasks

• Split feature flags functional tests into unit and functional
• Make Schema Validation errors more granular (backwards compatible!) to decouple tests (match="...")
• Review areas where we can make testing easier to author and less error-prone
• Identify slowest areas that contribute to tests being the slowest in our test suites (e.g., we're unnecessarily creating a dict of anonymous lambda fns)

Why is this needed?

Feature flags tests are dubious in value and we tend to find newer bugs that are easily preventable - see #2058. We haven't invested much in refactoring feature flags since the early days, and rushed to launch for various reasons.

We need to pay tech debt and make it more robust, and more easily extensible (future bring-your-own-conditions of sorts, new Storage Layer).

Which area does this relate to?

Feature flags

Solution

No response

Acknowledgment

• This request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

[anafalcao]

Closing as not planned for now

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.