test(menu): add performance tests for mat-menu #20151
Conversation
googlebot
added
the
cla: yes
| selector: 'app-root', | ||
| template: ` | ||
| <button mat-button [matMenuTriggerFor]="menu">Menu</button> | ||
| <mat-menu #menu="matMenu"> |
There was a problem hiding this comment.
We support multi-level menus too. Should we have a test that captures it?
There was a problem hiding this comment.
Hmm I ran into a bit of an issue with this. The main things I wanted to test out for nested menus is 1. is there any slowdown with opening the root menu if there are a couple of nested menus, and 2. how long it takes to open a menu fully.
The problem (which I left a comment for) is that calling getHarness seems to be an expensive operation which makes figuring out how expensive opening up submenus are.
I am wondering if I should change the test from opening a nested menu fully to just opening a single nested menu like
setup: () => open root menu and call getHarness for the sub menu
prepare: () => close sub menu
work: () => open on sub menu
@crisbeto Lmk what are your thoughts
There was a problem hiding this comment.
Harnesses trigger change detection and wait for it to finish before every action so I'm not sure whether we should be basing our performance tests on them. @mmalerba do you think that we should use Protractor directly?
There was a problem hiding this comment.
Using protractor has it's own issues with cdk-overlay-container
There was a problem hiding this comment.
I don't think the harnesses explicitly run change detection in e2e tests (though I'm sure they cause it by clicking). I think using the harness to open/close pretty much boils down to the same thing you would be doing via protractor directly anyways. The part where the harnesses might add some overhead is in searching for submenus, e.g. await loader.getHarness(MatMenuHarness.with({ triggerText: 'Sub Menu 1' })) - it would be ideal if we could pause measuring while doing this and then resume again when we go to actually click it, kind of like a "setup" step but it runs in the middle of the test. Not sure if that's possible though
There was a problem hiding this comment.
Don't they also wait for animations for finish? @wagnermaciel it might be worth trying to import the NoopAnimationsModule.
There was a problem hiding this comment.
I was under the impression that we actually wanted to wait for animations to finish
There was a problem hiding this comment.
Ok, I think I figured out the correct solution here. The MatMenuHarness uses .sendKeys(Key.ESCAPE) to close it's menu. It does not call click on the .cdk-overlay-backdrop like I was trying to do. This avoids the issue I was running into while trying to use protractor for these tests, so no need to use harnesses here anymore.
mmalerba
added
action: merge
* test(menu): add performance tests for mat-menu * fixup! test(menu): add performance tests for mat-menu * fixup! test(menu): add performance tests for mat-menu * fixup! test(menu): add performance tests for mat-menu (cherry picked from commit 9b0cd3c)
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
No description provided.