feat(material/form-field): add error harness

[andrewseguin]

Add an error harness for client tests checking whether there are certain errors on the page. This is very common internally for tests checking validation.

The harness can be retrieved directly or through the form field.

I tried to check the right inheritance structure of other harnesses - might have gotten something mixed up on the way. Would appreciate a review making sure I've got the right inheritance of things. The harness tests passed so that's a good sign.

[crisbeto]

The existing form field harness has getTextErrors and hasErrors methods. Couldn't users depend on them instead? https://github.com/angular/components/blob/main/src/material/form-field/testing/form-field-harness.ts#L124

[devversion]

ohh, that makes it questionable if it should be a separate harness (like in this PR) or if we should encourage the existing methods. I didn't realize we have these- good point.

[andrewseguin]

There's a lot of internal apps that use MatError without using the form field. Whether or not they should is maybe a good thing to discuss, but right now there's no way to get these folks using a test harness to check MatError.

[crisbeto]

I'm not sure if we would get much benefit out of switching those apps to harnesses since MatError basically hasn't changed after we introduced it. Maybe instead of migrating those apps, we can leave TODOs for them?

[andrewseguin]

The benefit here is making sure there is consistency with guiding our users to use harnesses with our components. Otherwise we need to special-case "mat-error" in our lint rule, or in our docs, with some reason about why we wouldn't provide one for it.

It would have been better if we failed when mat-error was rendered outside a form field, but with about 500 HTML files in google3, I don't expect ever making that change. One could argue it's a useful directive for user's custom form fields.

[crisbeto]

Would it make sense to add this harness, but mark it as deprecated so people know to go through the form field one?

[andrewseguin]

I'm in favor of deprecating it if we can get users off mat-error in their custom form fields, but that would be a bigger undertaking. I don't think just deprecating the harness is sufficient, you would need to deprecate the use of the mat-error by users outside the form field.

It's really just an element with display: block; color: warn, but people will take what they see https://www.hyrumslaw.com/

[devversion]

I'm fine going with this approach. Two things/questions:

1. Should we also have something for mat-hint?
2. Should we replace the existing methods to rely on the error/hint harnesses?

[andrewseguin]

1. Yeah looks like mat-hint needs it to - There's about 120 HTML files using it outside form field
2. I think that makes sense - changed the current error APIs to use it in their implementation

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