- Issue created by @quietone
- πΊπΈUnited States dww
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. :( - πΊπΈUnited States dww
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. β ).
- π¬π§United Kingdom joachim
> 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.