Agregar atributo data-* a los diferentes elementos para poder acceder a ellos en pruebas automatizadas

[JaviOCC]

Hola, estamos llevando acabo un proyecto de pruebas automatizadas para los flujos críticos de hirers y como parte de las buenas prácticas, se recomienda agregar un atributo a los elementos para que sean fáciles de acceder y evitar utilizar selectores que cambien frecuentemente.
Que les parece la idea de pasarle una prop a los componentes ej: testId y atomic agregue un atributo data-* ej: data-testid y así evitar futuros problemas en caso de que llegara a cambiar el id o clase de los diferentes elementos? Este atributo seria específicamente para pruebas.
Cabe mencionar que este cambio no afectaría a los sitios que actualmente hagan uso de la librería.

Ejemplo de uso:

Y atomic lo agregue así:

Estas son algunas herramientas que nos lo recomiendan como buenas practicas:
https://docs.cypress.io/guides/references/best-practices#Selecting-Elements
https://playwright.dev/docs/selectors#best-practices

[Andrea-Esquivel]

@gpimentel91 @andr05 @rrosaG @MitziMtz @anakarencm @malagon91 @bloodysummers @Yasbek

[Drkger]

Yo veo bien el agregar estos data-* ya que tambien se pueden usar para tracking y cada vez veo mas que son usados en buenas practicas cuando los selectores o clases son dinamicos.

Aqui en la documentacion de Heap tambien recomiendan usarlos para poder tener un identificador unico e inmutable
https://help.heap.io/data-management/react-dom-minification/general-strategies-for-using-heap-with-a-minified-dom/

[jcuevas-occ-com-mx]

Si son más fáciles de acceder y evitamos usar selectores me parece una buena idea 👍

[cinthya-trejo-occ-com-mx]

Yo lo veo bien chicos 👍 solo hay que definir bien como va a quedar el atributo data-*

[cinthya-trejo-occ-com-mx]

y otra duda, en todos sus proyectos usan occ-atomic? o también https://github.com/occmundial/atomic ?

[JaviOCC]

Me parece que de lado de hirers no se utiliza esa librería. @gpimentel91

[Andrea-Esquivel]

En el caso del repo recruiter-selfService sí se hace uso de la librería que comenta @Yasbek

[ldiaz-occ-com-mx]

Ok, de acuerdo a la documentación que compartes sí parece la práctica correcta y recomendada apuntar a través de data-test-id. Como comenta Yas, entonces hay qué definir cómo vamos a estar manejando este atributo:

• Cómo se setea en un componente? (cómo debería enviarse el prop)
• Qué tipo de componentes lo requieren? (sólo componentes interactivos? componentes de layout también o de texto?)
• Puede un componente requerir más de un data-test-id?
  • Por ejemplo, en el componente Autocomplete debería poder configurarse un data-test-id para el input y otro para el droplist o algún otro subelemento? y cuál sería la convención para el nombrado de estos múltiples data-test-id en los props?
• Deberíamos definir alguna estrategia de nombrado para evitar name collisions? por ejemplo algo similar a la metodología BEM para que los data-test-id sean siempre únicos pero deterministas.

Esos son los puntos que se me ocurren ahorita, no sé si hay alguna otra cuestión que haya qué definir.

[JaviOCC]

Platicando mas de cerca con @ldiaz-occ, se propone lo siguiente

• De momento los componentes que se requiere tener este atributo serian los interactivos.
• Se les pasara la prop de testId la cual será opcional
• Para los componentes mas complejos ej: TextField, Modal, Droplist, se propone construir los ids de lado de atomic con base al testId que se le pase, como ejemplo en el Modal, pudieran existir tres componentes con los que se requiera interactuar: close icon, mainBtn, secBtn y la propuesta de nombrado tomando como base el testId = 'modal-datos-fiscales':
  close icon = ${testId}_close-icon = modal-datos-fiscales_close-icon
  mainBtn = ${testId}_main-button = modal-datos-fiscales_main-button
  secBtn = ${testId}_secondary-button = modal-datos-fiscales_secondary-button

Que les parece? @Andrea-Esquivel @gpimentel91 @ldiaz-occ @Yasbek @malagon91 @anakarencm @andr05 @DaniCuevas