Proposal: Prefer string matchers over regex in suggested queries

Hey team,

Currently, tools like testing-playground rely on the generated query suggestions that come from this project. By default the suggestions direct you towards using regex matchers with case insensitivity (e.g. /sign up/i) for accessible names.

I want to get your feedback on switching to suggest string matchers (e.g. 'Sign up') when a name is suggested.

This started as a discussion over here. As a heads up, that thread is old and I'm sure people's thoughts have changed.

Some examples taken from that thread of what drives me to propose this:

• Ensuring that querying exactly as expected so we don't end up with casing that is undesired, like turkey vs Turkey, Polish vs polish, march vs March which can all be interpreted differently.
• Languages that don't have different cases like Japanese don't need case insensitivity.
• Teams sometimes run into accessibility changes where the combination of parent/child components alter how accessible names are built. Regex matchers can lead to tests passing when the desire would be for it to fail as the assistive technology will read it differently.

Proposed behaviour

Preferring string matchers makes tests more explicit and ensures they reflect exactly what users see and hear from assistive technologies. The principle behind testing library is "The more your tests resemble the way your software is used, the more confidence they can give you.", leads me to believe that we should be preferring string matchers first, and regex for the times where we care to only do partial, or case-insensitive, or fuzzy matching.

// Current solution
screen.getByRole('button', { name: /sign up/i })

// Proposed solution
screen.getByRole('button', { name: 'Sign up' })

Impact

This would be a breaking change.

However, the resulting queries/tests would be simpler, more readable, and more accurate.

I'm hoping to hear your thoughts on this. I'm not aware of the edge cases or downstream effects to consider with this change, but I'm hoping you'll be able to help me on that and tell me any concerns.

Thanks for your time.

Begin by reviewing the proposed string-versus-regex matcher behavior and the linked testing-playground discussion. Identify the query-suggestion entry points and downstream effects before deciding whether the breaking change is feasible. Done would require an agreed design, including edge cases and updated suggestions.