6 etapas para refactorizar un caso de prueba de Jest
4 de septiembre de 2019
0 minutos de lecturaUna función poco conocida de Jest permite personalizar cómo se manejan los errores de aserción que muestra la consola cuando fallan las pruebas. Imagina el siguiente código de prueba, que necesita recorrer un objeto mediante programación para asegurarse de que las claves existan como se espera (usando la función expect):
La prueba está bien escrita. Ahora, imagina qué pasa si alguien del equipo hace algunos cambios en el código: agrega un archivo en una parte y se olvida de agregarlo en otra parte importante del mismo proyecto, como asegurarse de que se exporte correctamente.
La próxima vez que se ejecute la prueba, fallará. Sin embargo, para la mayoría no será evidente por qué; y si acabas de empezar a trabajar con el código, probablemente ni siquiera sabrás qué se rompió. Pruébalo:
Por eso, Jest también requiere usar toHaveProperty() con expect, así:
Ahora, cuando falla una prueba, al menos queda más claro qué propiedad falta. Sin embargo, como puedes ver en la siguiente captura de pantalla, sigue siendo un poco críptico. ¿Qué podemos hacer? ?
En este punto, las anotaciones que ya tenemos quizá sean suficientes. El nombre de la prueba se explica por sí solo, como puedes ver. Pero solo tenemos un caso de prueba que falla y, al revisar el seguimiento de la prueba, no podemos determinar claramente qué validadores se usaron.
Refactoricemos el código:
Ahora, cuando mi prueba pasa o falla, queda mucho más claro e intuitivo qué se probó exactamente, qué falló exactamente y por qué:
¡Mucho mejor! ???
Si te gusta Jest tanto como a mí (?) quizá también te interese leer algunos de mis otros artículos sobre Jest:
Si también te interesa la seguridad web, me encantaría conocerte en la comunidad de Slack de The Secure Developer o en Twitter, si eso es más lo tuyo.