-
Notifications
You must be signed in to change notification settings - Fork 6.8k
feat(material-experimental): add test harness for select #16710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Sets up the test harness for `mat-select`.
74f8994
to
5a3ddb7
Compare
} | ||
|
||
/** Gets the select panel. */ | ||
async getPanel(): Promise<TestElement> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a reason to expose this element? what would a user do with it in a test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use it to look at the scroll position and the position of the dropdown itself. We have a bunch of our own tests that deal with the dropdown.
} | ||
|
||
/** Gets the options inside the select panel. */ | ||
async getOptions(): Promise<TestElement[]> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could potentially expose an OptionHarness
and OptionGroupHarness
to make it easier to work with these. I'm not sure if its overkill for this case, but I kind of like the idea of avoiding giving the user TestElement
references when possible.
I would at least add an optional parameter to these methods so I can do something like getOptionGroups('Food')
or getOptions('Pizza')
. If you make a OptionHarness
this could be an OptionHarnessFilters
instead of a string.
Curious if @jelbourn has an opinion here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do it on the second pass once both the autocomplete and select harnesses get in since both of them use mat-option
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I think we should have harnesses for the options. It can go in a follow-up PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add TODO
for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, can do options in a follow-up
LGTM, please just add a TODO about the option harness |
Sets up the test harness for `mat-select`. (cherry picked from commit 89c784c)
Follow-up from angular#16620 and angular#16710. Adds a dedicated harness for `mat-option` and `mat-optgroup`. Note that some of the code is duplicated. This is because we don't have a shared place where to put the harness so that `mat-autocomplete` and `mat-select` don't have to depend on each other. I've intentionally kept the harnesses to only the methods we need, but once we have `experimental/core`, I'll combine them and implement all of the states that are supported by `mat-option`.
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. |
Sets up the test harness for
mat-select
.