Capítulo 21. Pruebas frontales
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
En capítulos anteriores, mencioné que la mejor práctica para escribir cualquier prueba es hacerlo al mismo tiempo que escribes cualquier funcionalidad nueva o haces cualquier refactorización. Las pruebas merecen su propio enfoque, y eso es lo que trataré aquí.
Cuando estés construyendo esta aplicación, debes asegurarte de que no estás liberando regresiones en la funcionalidad existente. Una regresión es cuando un código nuevo provoca involuntariamente errores en la funcionalidad existente en cualquier parte de la aplicación. El equipo de control de calidad, si existe, no tendrá tiempo de realizar pruebas de regresión en cada versión, pero como desarrollador, puedes tomar la iniciativa para asegurarte de que tu código es sólido. Tus pruebas para el nuevo código pueden plantear preguntas sobre cómo funciona algo o qué ocurre cuando no funciona.
En este capítulo trataré:
-
Cómo determinar qué partes del frontend hay que probar
-
Pruebas unitarias
-
Pruebas de extremo a extremo (e2e)
-
Herramientas de comprobación útiles
Los dos objetivos de la escritura de pruebas son evitar que un código roto inesperado acabe delante de los usuarios y documentar la aplicación para que todo el mundo sepa cómo se supone que debe funcionar. Las pruebas también te dan más confianza para futuros desarrollos, porque no te preocupa que tus cambios rompan ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access