Skip to content

feat(material/list): add test harnesses for list components. #17859

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

Merged
merged 7 commits into from
Dec 4, 2019

Conversation

mmalerba
Copy link
Contributor

@mmalerba mmalerba commented Dec 2, 2019

No description provided.

@mmalerba mmalerba added the target: minor This PR is targeted for the next minor release label Dec 2, 2019
@mmalerba mmalerba requested review from jelbourn and crisbeto December 2, 2019 23:06
@mmalerba mmalerba requested a review from devversion as a code owner December 2, 2019 23:06
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Dec 2, 2019
@mmalerba mmalerba requested a review from a team as a code owner December 3, 2019 00:44
text?: string | RegExp;
}

export interface ListItemHarnessFilters extends BaseListItemHarnessFilters {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to just have ListItemHarnessFilters be the base type instead of having a separate BaseListItemHarnessFilters type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It didn't feel right since the other types don't actually extend MatList. However, I don't really see needing to add a filter for normal list items that doesn't also apply to the other list item types, so it would probably be fine if we want to do that.

Copy link
Contributor Author

@mmalerba mmalerba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the comments addressed, will move the files around in a followup commit to make following the comments easier.

export interface SelectionListHarnessFilters extends BaseHarnessFilters {}

export interface BaseListItemHarnessFilters extends BaseHarnessFilters {
text?: string | RegExp;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. Because the list doesn't have hierarchical sections, its not always clear if an item belongs to a header or not. e.g.:

Subheader 1
  Item 1
  Item 2
-----------
  Item 3 <-- under Subheader 1?

text?: string | RegExp;
}

export interface ListItemHarnessFilters extends BaseListItemHarnessFilters {}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It didn't feel right since the other types don't actually extend MatList. However, I don't really see needing to add a filter for normal list items that doesn't also apply to the other list item types, so it would probably be fine if we want to do that.

@@ -15,12 +15,14 @@ entryPoints = [
"dialog",
"dialog/testing",
"divider",
"divider/testing",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's consistent, but it feels a little silly to have a test harness for what is basically a div.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah its a little silly, but there are actually couple methods on it, and just having the selector encapsulated in a harness is kind of nice


/** Harness for interacting with a list subheader. */
export class MatSubheaderHarness extends ComponentHarness {
static hostSelector = '[mat-subheader], [matSubheader]';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't we running the risk of these selectors going out of sync? Maybe in a follow-up we should pull them out into variables?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'll be ok, usually when I remove a selector I do a global search for e.g. 'mat-subheader' to find and fix them all, that should catch this.

@mmalerba
Copy link
Contributor Author

mmalerba commented Dec 3, 2019

Comments addressed, PTAL

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Dec 3, 2019
Copy link
Member

@crisbeto crisbeto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn merged commit 49b6dbd into angular:master Dec 4, 2019
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jan 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants