Soften language around feature spec deterrence
What does this MR do and why?
Soften language around feature spec deterrence
- the current language lends itself to perhaps feature specs too easily being dismissed and could lead to possible testing gaps.
- feature specs have immense value for many reasons(with downsides of course):
- testing the glue between backend and frontend
- user journeys like registration/onboarding
- we should reach for them more often and test in the code what we can before
reaching for e2e tests in the qa/ directory that may or may not get created
- merely some thoughts, but the core goal here in this MR is merely to soften the language first to get more consideration around using them and maybe that is all we do here for now.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #452216