Pruebas en React: El viaje de un converso de Enzyme a Testing Library

Gracias por venir a esta charla donde hablaré sobre por qué cambié de Enzyme a la biblioteca de pruebas de REACT cuando se trata de pruebas de REACT. Entonces, Enzyme y la biblioteca de pruebas de REACT, hacen el mismo trabajo. Básicamente, si estás ejecutando pruebas unitarias e integradas sin un navegador, necesitas un DOM virtual. Necesitas un DOM para poder interactuar con tu aplicación y para poder probar el comportamiento de tu aplicación, que es el punto de las pruebas después de todo.

Aquí hay una breve cronología. En 2016, Airbnb lanzó por primera vez Enzyme, y luego en 2018, Kent C. Dots lanzó la biblioteca de pruebas de REACT. Esto solo te da un contexto para saber que cuando comencé a probar REACT en 2016, usé Enzyme porque la biblioteca de pruebas no existía. Enzyme también se adaptaba muy bien a mi forma de probar. Me gustaba tener pruebas muy meticulosas, muchas pruebas unitarias que estuvieran realmente aisladas, usando muchos mocks, y debido a que estaban aisladas, necesitaba probar detalles de implementación como el estado. Avancemos rápidamente hasta 2020, y mucho ha cambiado, incluyendo el hecho de que las mejores prácticas de pruebas de React se han definido mejor, y la biblioteca de pruebas, que ayuda a definir y aplicar esas mejores prácticas, es muy popular. Al principio, me resistí mucho a la biblioteca de pruebas. Mi enfoque de pruebas estaba en peligro, no quería que alguien más me dijera cómo hacer mis pruebas. Pero quedó claro que la biblioteca de pruebas no iba a desaparecer. Así que decidí probarla. Resulta que me he convertido por completo. Así que te daré algunas de las razones por las que ahora prefiero la biblioteca de pruebas.

La biblioteca de pruebas es conocida por ser opinativa, lo que significa que fomenta las mejores prácticas al facilitar hacer lo correcto y dificultar hacer lo incorrecto. Las mejores prácticas incluyen interactuar con tu aplicación de la misma manera que lo harían los usuarios y probar el comportamiento. Básicamente, tus pruebas toman una entrada similar a la de un usuario y prueban una salida similar a la de un usuario, lo que hace más probable que tus pruebas tengan éxito cuando el comportamiento del usuario es correcto y que fallen cuando el comportamiento del usuario no lo es. Como consecuencia de esto, tus pruebas no necesitarán ser reescritas cuando refactorices tu código. Y con refactorizar me refiero a cambiar cómo está escrito tu código, pero sin cambiar el comportamiento. Entonces, React está en constante evolución. Recientemente, ha habido un cambio de componentes basados en clases a componentes funcionales y tu aplicación evolucionará con React, pero siempre y cuando el comportamiento no cambie, tus pruebas no necesitarán actualizarse. Otra de las mejores prácticas fomentadas por la biblioteca de pruebas de React es el código accesible. Recomiendan encontrar elementos de la misma manera que lo harían los lectores de pantalla u otras tecnologías de asistencia. Mi código se ha vuelto mucho más accesible desde que comencé a usar la biblioteca de pruebas, simplemente me he vuelto mucho más consciente de la accesibilidad. En Enzyme es posible encontrar elementos basados en identificadores de accesibilidad, pero es mucho más difícil. Ahora, me gustaría hablar sobre dos bibliotecas en el ecosistema de la biblioteca de pruebas que realmente mejoran tu código, y por eso, quiero mostrarte una comparación entre cómo se vería el código en Enzyme y cómo se ve en la biblioteca de pruebas. La primera biblioteca es user event, y esto es para las interacciones.

Entonces, tomemos un ejemplo donde como parte de tu prueba, necesitas escribir texto en un campo de entrada. En Enzyme, tu código se vería así. Estarías simulando un cambio, y el cambio es que estarías cambiando el valor del objetivo. Esto no es muy legible y no simula cómo interactúan los usuarios. Los usuarios no envían eventos de cambio. La biblioteca de pruebas con user event, por otro lado, es mucho más legible. Estás escribiendo 'hola mundo' en tu elemento. Esto también tiene opciones donde puedes simular el comportamiento del usuario de una manera más detallada. Usando retrasos en la escritura, haciendo clic en el elemento antes de escribir, y así sucesivamente. Así que aquí hay una gran mejora.

Las aserciones del DOM también mejoran las aserciones que puedes usar en Enzyme. Y para esto, voy a usar el ejemplo de verificar que un elemento ya no es visible después de alguna interacción del usuario. En Enzyme, puedes esperar que tu propiedad de estilo tenga visibilidad oculta, por lo que esto también es un código engorroso, y ni siquiera cubre todas las posibilidades. Hay muchas otras razones por las que tu elemento puede no ser visible, como la propiedad display y la opacidad. Con solo el DOM, tienes esta hermosa aserción concisa: espero que mi elemento no sea visible. Así que es más legible. Y también verifica todas las razones por las que tu código, perdón, tu elemento puede no aparecer en la página.

Entonces, en conclusión, estas son las razones por las que prefiero la biblioteca de pruebas. Es opinativa, lo que facilita seguir las mejores prácticas. Fomenta un código accesible para asegurarse de que tus pruebas puedan encontrar elementos de la misma manera que las tecnologías de asistencia pueden hacerlo. Y el código es simplemente mejor. Es más legible y simula más cómo interactúan realmente los usuarios. User event es muy útil para las interacciones, y JustDOM es útil para las aserciones. En general, obtiene mi aprobación.