[policy, no patch] Improving the test suite

Thanks for opening this! Not sure if this should be "policy, no patch", or "meta", or... 😅

Added the key final point from my comment that this issue was split off to address 🌱 [policy, no patch] Better scoping for bug fix test coverage RTBC :

Prioritize (like core initiative style) efforts to rationalize, standardize and clean-up our existing tests.
We've learned *a lot* as a community about tests over the last ~6+ years, but lots of our tests haven't caught up to that. The tests for Views module, for example, are completely whack. Many views handlers have dedicated Kernel tests for them (yay), but other handlers are only tested via previewing a view in the views UI with a Functional test (WTF?). Part of why writing new tests is so hard is that if you look for existing test coverage of something, it's very unlikely you'll find it, and if you do, you might find a completely absurd thing to base your new test on. :(

Also adding the 5th point. 😅

Make it easier and faster to iterate on tests in the issue queue (e.g. #2569585: Split incoming patches into psr0/psr4 tests and code and run just new tests first. → ).

> Prioritize (like core initiative style) efforts to rationalize, standardize and clean-up our existing tests.

That could come under the 🌱 Boilerplate reduction initiative Active which I am trying to get up and running.

> The tests for Views module, for example, are completely whack.

Yes! And the setup that the tests do to create views is crazy as well.

Thanks for pointing out the other issues. That shows there are concrete efforts to improve testing.

Looking at the topics in the issue summary, I wonder if this issue is the place to make progress, especially since there has only been two voices here.

• Make writing tests easier - How to do this? Is this through mentoring or tutorials in documentation or something else?
• Better document the existing tests - While true, is it in the best interest of the project to spend time on improving the docs on existing tests?
• Incentivize test writing - There are 2006, about 13%, of open issues in core that are tagged 'needs tests'. Is that a high enough percentage that incentives are needed?
• Prioritize (like core initiative style) efforts to rationalize, standardize and clean-up our existing tests. - Anyone can start and initiate, so this issue isn't needed to approve that.
• Make it easier and faster to iterate on tests in the issue queue (e.g. #2569585: Split incoming patches into psr0/psr4 tests and code and run just new tests first.). - Is there an issue for this for GitLab?

Although I created this followup I think it better to spend our time on existing concrete efforts. Shall we close this?