Entiendo que el enfoque de React Testing Library es consultar elementos DOM de una manera que tenga sentido desde la perspectiva del usuario (por ejemplo, por rol o texto visual). Además, en los documentos RTL, hay una lista aproximada de prioridades de qué método de consulta usar cuando sea posible.
Sin embargo, ¿existe una lista de prioridades aproximada/preferencia por un método particular de consulta de elementos convencionalmente inaccesibles también? Como, por ejemplo, divs anidados que contienen clases de estilo importantes para probar.
Soy consciente de 3 formas posibles:
role y aria-label , lo que hace que el elemento sea accesible a través .queryByRole()data-testid y luego consultar a través .getByTestId()const { container } = render(<Component />); .Quiero enfatizar que entiendo que estos son anti-patrones y deben evitarse tanto como sea posible. Pero, si es necesario, ¿cuándo es mejor usar cada uno de estos métodos? ¿Existen alternativas adicionales a la consulta de elementos inaccesibles que también deberían considerarse circunstancialmente?
Siempre se debe preferir obtener un elemento por Rol y su nombre accesible. Al usar HTML semántico , no es necesario establecer explícitamente el rol del elemento y es la forma preferida de definir roles accesibles. Si su elemento no está disponible en su árbol de accesibilidad, probablemente significa que está alterando las reglas de HTML (p. ej., div dentro de un button no está permitido y hace que su botón sea inaccesible). Puede validar su HTML usando Nu HTML Checker .
Cuando se trata de entradas, obtener el elemento byLabelText debe ser la forma preferida, ya que valida que su entrada tenga una etiqueta accesible.
Establecer un data-testid es la última forma de obtener un elemento. Por ejemplo, si está probando la presencia de un panel sin ningún rol accesible.
Se desaconseja manipular directamente el DOM (en mi experiencia personal nunca lo he usado). Debe evitarse porque la estructura del DOM podría variar con más frecuencia que el rol accesible (por ejemplo, con fines de diseño), lo que hace que sus pruebas sean más frágiles.