-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
feat(material/tabs/testing): polish harness API #17417
Conversation
7b1c2ea
to
32d4db8
Compare
/** Gets the element id for the content of the current tab. */ | ||
private async _getContentId(): Promise<string> { | ||
/** Gets a selector that can be used to locate the tab's content element. */ | ||
async getSelectorForContent(): Promise<string> { |
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.
What about getting a locator scoped to the content?
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 in general.
@mmalerba I'm somewhat hesitant in thinking that returning TestElement
's is an anti-pattern. For simple assertions where someone wants to get a handle on the content element, it feels totally expected to me that a TestElement
instance is returned that works for both e2e and test bed tests.
The abstraction of the elements we are dealing with in the harnesses is not only useful to implementer's of harnesses, but also to consumers of harnesses as they do not need to deal with platform-specific things (i.e. calling querySelector
). I don't see any big impact on providing such a harness method (it seems like it can be quite useful and commonly used)
32d4db8
to
497e7eb
Compare
As discussed on slack, switch to returning a |
ba9e030
to
21328f6
Compare
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
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.
Nice! I really like that harness loader method 🎉
21328f6
to
25daee6
Compare
25daee6
to
50a1b19
Compare
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. |
label
filter forMatTabHarness
MatTabGroupHarness#getTabs
MatTabGroupHarness
getContentElement
and replace it withgetHarnessLoaderForContent
@jelbourn @devversion Curious about your opinions: My reason for removing
getContentElement
is that I want to avoid returningTestElement
objects from our harnesses. I don't think they're particularly useful to test authors, and instead we probably want APIs that are more focused in purpose. I do think it makes sense, however, to allow users to get some handle on the content. I think the thing users are most likely to do with the content element is either query for more harnesses within it, or query outside of the harness system (e.g.document.querySelector
). I settled on returning a selector because it allows the user to do either of those things. Another option would be to provide a method for loading a sub-harness directly (they pass the harness class and we return an instance). We either could provide this method instead of or in addition to thegetSelectorForContent
method.Update: Changed
getSelectorForContent
togetHarnessLoaderForContent