Problem/Motivation
HandlerAllTest makes no HTTP requests but is a functional test.
Proposed resolution
Convert HandlerAllTest into a kernel test.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|
Issue fork drupal-3041755
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3041755-convert-handleralltest-into
changes, plain diff MR !6195
Comments
Comment #2
claudiu.cristeaThis patch decreased the test time, locally, from 20 to 4 seconds.
Comment #3
amateescu commentedAwesome!
Comment #4
alexpottThis is not quite testing the same things. If I do var_dump(count($this->container->get('views.views_data')->get())); in the functional test I get
This test printed output: int(49)and if I do in the kernel test i getThis test printed output: int(37).Comment #5
lendudeLooking at the history of this test in #1777194: One handler test to rule them all it seems the idea behind it was to test all the handlers in core, so it enabled all the modules that had views handlers and tested them.
So instead of removing these modules, we should be adding more modules, that have been added to core in the time since the original issue, that contain views handlers
Comment #16
spokjeComment #17
smustgrave commented1 nitpicky item. But how we have done other conversions think it should be included.
Comment #18
spokjeComment #19
smustgrave commentedThanks @Spokje
Comment #20
spokjeComment #21
longwaveI repeated #4 and there is still a difference (but also see how much quicker the kernel test is):
vs
Maybe we need some additional coverage to ensure all handlers in core are included?
Comment #22
lendudeAdded some more modules
Checked all modules that implement hook_views_data, think this get all of the ones that don't need extra handling or just reuse existing plugins...I think
Comment #23
smustgrave commentedFeedback appears to be addressed.
Comment #24
spokjeDo we need either a follow-up or some more work in here to make sure that adding modules with views handlers to core, but not to this test. would break either this test or another new test?
Comment #25
catchI think a follow-up to add a test coverage test is probably a good idea, the old test would not have caught new modules either so not a requirement for me, but useful to have.
Comment #28
catchCommitted/pushed to 11.x and cherry-picked to 10.2.x, thanks!