feat(select,input,form-field): move test harnesses out of experimental

[crisbeto]

Moves the test harnesses for the select, input and form-field packages out of material-experimental.

[crisbeto]

Note that we have a harness for an option inside mat-select, as well as for an option in mat-autocomplete. Once this PR is merged in I can remove the duplication and add a single, fully-featured harness for mat-option in core.

[mmalerba]

It would be really nice if we could get that in before final. I forgot that autocomplete was already moved out of experimental with the split mat-option harness

[crisbeto]

Setting to P2 since there's other work that depends on these changes.

[jelbourn]

LGTM

[devversion]

LGTM.

[mmalerba]

Sorry, it won't let me add comments inline since the lines are unedited, but here's a breakdown by class of changes I think we should make before moving this API out of experimental:

FormFieldHarnessFilters
	+ floatingLabelText?: string | RegExp
	+ hasErrors?: boolean

MatFormFieldHarness
	+ hasErrors(): Promise<boolean>
	+ getHarnessLoaderForInfix(): Promise<HarnessLoader>
	getPrefixContainer => getHarnessLoaderForPrefix
	getSuffixContainer => getHarnessLoaderForSuffix
	getErrorMessages => getTextErrors
	getHintMessages => getTextHints

InputHarnessFilters
	+ placeholder?: string | RegExp

SelectHarnessFilters
	+ placeholder?: string | RegExp
	+ value?: string | RegExp

MatSelectHarness
	+ select(filters?: SelectOptionHarnessFilters): Promise<void>
	getOptions => add optional filters
	getOptionGroups => add optional filters

Also, do a pass on the API docs, make sure they are consistent with other harnesses (in particular I noticed with method, move description of filter options to the filter class).

[crisbeto]

@mmalerba I've updated the harnesses based on your feedback, aside from a couple of issues:

1. I'm not sure how getHarnessLoaderForInfix(): Promise<HarnessLoader> is supposed to work and what it would be useful for. We already have harnesses for the input and select which expose the content inside the infix.
2. I don't think we can do the value and placeholder filters for the select harness, because the values aren't always in the DOM so we can't extract them reliably.

[mmalerba]

Discussed with @crisbeto on slack. After thinking about it more, I agree that those two don't make sense

[mmalerba]

Do you have a particular use case in mind for MatSelectHarness#getPanel? I'd prefer to remove it, it goes against my rule of thumb about exposing TestElement.

[crisbeto]

I added getPanel, because I thought that it might useful if somebody wants to get info that we haven't exposed directly in the harness. I've removed it, can you take a look @mmalerba?

[mmalerba]

• Do you disagree on renaming getErrorMessages and getHintMessages or did you just miss it? My reasoning is that in other harnesses we named methods like that when they returned the text of the element rather than the element itself
• It looks like option is not exported from public-api for select
• getOptionGroups should also take optional filters
• The doc comments for filter classes and with methods still needs to be udated

[mmalerba]

Based on the name of this method, I would expect it to call select on the option rather than click (which is effectively toggle). Maybe we can change this to call select() on the options and then also have a deselect() method that calls deselect() on the options.

[crisbeto]

These are the custom mat-option elements so we don't have access to the select/deselect methods. Should I rename it to click instead?

[mmalerba]

You can leave it as is for now and leave a TODO to split out separate select/deselect methods later

[crisbeto]

@mmalerba I've addressed the latest set the feedback, aside from exposing the option harnesses. I haven't exposed or documented them properly yet, because their code is duplicated between mat-select and mat-autocomplete. Once this PR is merged in I'll add proper, fully-featured harnesses that are exposed through material/core/testing.

[mmalerba]

I'm hesitant about just merging this and doing the option stuff in a follow up because I don't want this temporary state API to wind up in an RC, or worse final if the follow-up doesn't make it in in time. I would suggest doing the common option first and putting this one on hold until that's in.

cc @jelbourn

[crisbeto]

I can put together the option PR for Monday so we have some time to merge it in for final. I would've made a shared option harness to begin with, but the autocomplete and select harnesses started off in experimental and we don't have a material-experimental/core to put it in.

[jelbourn]

I'm fine with doing this in two steps since I just did an RC today and will know not to do another one until we consolidate

[mmalerba]

Ok, last couple things then we can merge

[crisbeto]

Addressed the last few things @mmalerba.

[angular-automatic-lock-bot]

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.}