Principios de Prueba o Testing de Front-End

6 minuto(s)

En esta página:

Escribir pruebas de front-end puede ser muy difícil. Tienes tantas cosas que considerar, opciones que tomar y caminos que puedes tomar. En este artículo, veremos 5 Principios de Prueba o Testing de Front-End, para escribir mejores pruebas y brindarte total confianza para impulsar nuevas funciones en producción. Recuerda ponerlas en práctica en tus próximos proyectos, ya que la mejor manera de dominar un tema es practicándolo, como se dice, la práctica hace al maestro, bien vamos con este Post.

Antes de continuar, te invito a escuchar el Podcast: “Las Buenas Prácticas Un Hábito Importante en la Programación” y “¿ Porqué Es Importante Saber Programar en la Ciberseguridad ?” (Anchor Podcast)”:

Spotify:	Sound Cloud:	Apple Podcasts	Anchor Podcasts

Bien ahora continuemos con el Post: Principios de Prueba o Testing de Front-End.

Antes de comenzar, es importante mencionar que este artículo es: Centrado específicamente en las pruebas de front-end (es decir, aplicaciones React, Vue JS, Angular, etc. y sus interacciones con los componentes).

Pruebe Tu Software de la Misma Manera Que Lo Usan Tus Usuarios

Queremos escribir pruebas mantenibles que le brinden una alta confianza de que sus componentes funcionan para sus usuarios. Y para el Front-End, debemos centrarnos en solo dos objetivos para nuestras pruebas:

El usuario final que interactúa con su componente en el navegador.
El desarrollador que renderiza y usa su componente en el código.

Pero con demasiada frecuencia introducimos un tercer usuario, el usuario de prueba. Este usuario suele probar cosas que ni a nuestros consumidores ni a nuestra empresa les importan (por ejemplo, probar los detalles de implementación).

Pero al probar de esta manera, solo estás obteniendo confianza para un usuario que:

No paga las facturas como el usuario final.
No afecta al resto del sistema como el usuario desarrollador.

Además, ahora debes tener en mente a ese tercer usuario y asegurarte de tener en cuenta los cambios que afectan al usuario de prueba.

Evite Probar Los Detalles de Implementación

El usuario de prueba tiende a probar lo que se llama “detalles de implementación”. Y los detalles de implementación pueden conducir a:

Falsos negativos: pueden romperse cuando refactorizamos el código de la aplicación.
Falsos positivos: no pueden fallar cuando rompemos el código de la aplicación.

Es por eso que en la mayoría de los casos queremos evitarlos , lo que hará que nuestras pruebas:

Más cerca de cómo nuestros usuarios (usuario final y desarrollador) usan nuestros componentes. Lo que nos da la confianza de que nuestra aplicación está funcionando según lo previsto.
Más resistente. Los refactores de sus componentes no romperán nuestras pruebas y, por lo tanto, no ralentizarán a nuestro equipo ni a nosotros.

Tus pruebas deben estar más enfocadas en casos de uso reales que tus usuarios puedan conocer.

¿ Cómo determinar un detalle de implementación ?

Si nuestra prueba hace algo que el consumidor de nuestro código no hace, entonces estás probando los detalles de implementación. (Exponiendo una función privada a modo de ejemplo).
Si un refactor interno (cambios en la implementación pero no en la funcionalidad) rompe sus pruebas, entonces estás probando los detalles de la implementación.

Ejemplo de “detalles de implementación”:

Estado interno de un componente
Métodos internos de un componente
Métodos del ciclo de vida de un componente
Componentes secundarios

Es importante notar que todavía hay algunos casos que requerirían probar los detalles de implementación. En React, podemos pensar, por ejemplo, en un enlace personalizado con mucha lógica interna y que se compartiría en tu aplicación.

Pero esos los usuarios que probarán tu aplicación, deben ser raros y bien elegidos.

Escribe Menos Pruebas y Más Largas

Muchas personas leen la lista de requisitos para un componente y los convierten en casos de prueba individuales. Tal vez hayas leído acerca de la llamada “mejor práctica de solo una aserción por prueba”. Pero esa regla se creó originalmente porque los frameworks de prueba hicieron un mal trabajo al brindar información contextual que necesitaba para determinar qué estaba causando las fallas de una prueba.

Hoy en día, gracias a las increíbles herramientas que existen, identificar qué aserción resultó en la falla es trivial. Y si deseas dejar las cosas aún más claras, puedes agregar un comentario de código sobre la afirmación para explicar qué es importante acerca de esa afirmación que estás haciendo.

No te preocupes por tener pruebas largas. Cuando estás pensando en tus dos usuarios y evita el usuario de prueba , entonces tus pruebas a menudo involucrarán múltiples acciones y afirmaciones y eso es algo bueno. No separes arbitrariamente tus afirmaciones en bloques de prueba individuales, no hay una buena razón para hacerlo.

¿ Cómo determinar tu prueba ?

Piensa en un flujo de trabajo de caso de prueba para un probador manual e intenta hacer que cada uno de tus casos de prueba incluyan todas las partes de ese flujo de trabajo.

Escribe Tus Pruebas Teniendo en Cuenta la Facilidad de Comprensión y Mantenimiento

El principio de programación AHA significa “Evitar la abstracción apresurada”. Dice que no debes ser dogmático acerca de cuándo comienzas a escribir abstracciones, sino que escribas la abstracción cuando te sientsa bien y no tengas miedo de duplicar el código hasta que llegue allí.

Encontrar un punto óptimo en medio del espectro de abstracción es clave para desarrollar un código sostenible.

Ese principio se puede aplicar totalmente a la escritura de pruebas mantenibles. Como recordatorio, escribe una prueba para tener la confianza de que el código que estás insertando en producción hoy no se romperá en caso de un cambio más adelante.

Pero las pruebas también deberían ser una ayuda para ti o cualquier otro desarrollador que pueda volver a ellas en el futuro para comprender fácilmente cuál es el propósito del componente probado (en términos de funcionalidad y característica crítica). De esta manera, deseas que tu prueba sea fácil de entender y fácil de mantener .

Escribe Tus Pruebas de Forma Aislada

Tener pruebas aisladas significa que los efectos secundarios de ejecutar una prueba no deberían influir en los resultados de otras pruebas. Deberíamos poder ejecutarlas independientemente en cualquier orden, sin cambiar el resultado obtenido.

Tener pruebas aisladas es un principio importante de las pruebas en general porque es una de las causas principales de las pruebas inestables (pruebas que no producen el mismo resultado cada vez que las ejecutamos) cuando no se respetan.

Dado que las pruebas deben ser independientes y su orden de ejecución no importa, Jest puede ejecutarlas en paralelo, lo que mejora considerablemente el tiempo total de ejecución.

Escribir nuestras pruebas de forma aislada nos guiará hacia una mejor manera de escribir pruebas para mejorar su confiabilidad, simplificar el código y aumentar la confianza.

Cuidado con los Simulacros

Los simulacros se consideran mecanismos provisionales que nos permiten probar ciertas cosas que de otro modo serían difíciles o perezosas de probar (por ejemplo: probar un servicio de tarjeta de crédito, no queremos jugar con los datos y servicios de producción, por lo que el dinero real ).

Ten en cuenta que cuando nos burlamos de algo, estamos haciendo una compensación. Por lo general, cambiamos la confianza por la practicidad. Incluso si confiamos en que nuestro código funciona con nuestra versión falsa del servicio, no podemos confiar al 100 % en que nuestro código funcionará en producción con la versión real.

Definitivamente hay algunos lugares para simulacros (en particular, cuando hablamos de los diferentes niveles de prueba), pero debemos ser conscientes de que hacemos un intercambio.

Conclusión

Como mencione, las pruebas de front-end son un desafío. Para escribir pruebas relevantes, debes separarte de tu propia mentalidad de desarrollador y, en cambio, tratar de pensar como lo haría un usuario real, considerando la interfaz de usuario como un todo. Dado que otros desarrolladores vendrán detrás de ti para agregar sus propias piezas de código y pruebas, también debes prestar mucha atención a la mantenibilidad y la comprensión.

Recuerda que el propósito principal de escribir pruebas es aumentar tu confianza en tu aplicación. Deseas asegurarte que la funcionalidad implementada funcione hoy como se esperaba y no se rompa en el futuro. Escribir pruebas por escribir pruebas (o hacer coincidir la cobertura de código mínima arbitraria) no tiene valor y, a menudo, resulta en una pérdida de tiempo y dinero. Espero que estos principios te ayuden en este viaje.