Crea pruebas funcionales automatizadas dentro de tus paquetes que ejecuten los casos de prueba de forma autom\u00e1tica. Usa esto como parte de tu programa de control de calidad para descubrir y solucionar errores antes de que tu aplicaci\u00f3n pase a producci\u00f3n.<\/div>\r\n <\/div>\r\n\n\n\n
Por qu\u00e9 deber\u00edas evitar las pruebas manuales y qu\u00e9 hacer en su lugar<\/h2>\n\n\n\n
Lo opuesto a las pruebas funcionales son las pruebas manuales. Las pruebas manuales son un tipo de pruebas de software en las que los casos de prueba son ejecutados manualmente por un profesional de pruebas sin utilizar ninguna herramienta automatizada. Siempre debes centrarte en las pruebas funcionales en lugar de en las manuales, ya que una prueba manual es propensa a errores y no es reproducible.<\/p>\n\n\n\n
Gran parte del equipo de programaci\u00f3n comete el error de ejecutar un servicio localmente y realizar pruebas manuales en los puntos de conexi\u00f3n para diagnosticar problemas. Despu\u00e9s de haber hecho esto durante muchos a\u00f1os, no te podemos contar de primera mano la cantidad de veces que hemos reproducido un problema sin saber exactamente c\u00f3mo lo logramos, lo que ha provocado que quisi\u00e9ramos lanzar mesas por los aires al intentar desandar nuestros pasos.<\/p>\n\n\n\n
Las sesiones de depuraci\u00f3n a menudo pasan de durar horas a durar d\u00edas, y con las pruebas manuales todos los escenarios que probamos quedan sin documentar y se difuminan entre s\u00ed. Sin embargo, si todos estos escenarios intentados se redactan como pruebas funcionales<\/b>, cada escenario puede pasar a formar parte del historial de la sesi\u00f3n de depuraci\u00f3n.<\/p>\n\n\n \r\n\r\n
Si escribes pruebas funcionales para escenarios nuevos, pueden convertirse en parte del paquete de pruebas de regresi\u00f3n que se ejecutan durante la integraci\u00f3n continua (CI).<\/div>\r\n <\/div>\r\n\n\n\n
Hay un secreto para las pruebas funcionales. Escribir pruebas funcionales para diagnosticar problemas es una estrategia clave para minimizar el tiempo de resoluci\u00f3n de los errores. Sin embargo, este m\u00e9todo de diagn\u00f3stico no funciona si escribir la prueba funcional resulta dif\u00edcil. \u00bfLa soluci\u00f3n? Simplifica las cosas desde el primer paso.<\/p>\n\n\n\n
Crea un paquete de funciones auxiliares y aserciones sencillas.<\/b> El objetivo es que las acciones, como los bucles de reintento y la importaci\u00f3n de paquetes de datos, resulten MUY f\u00e1ciles de realizar. Estas funciones auxiliares deber\u00edan estar entre las primeras herramientas creadas durante la redacci\u00f3n inicial del software para brindar asistencia a las nuevas pruebas funcionales en el futuro.<\/p>\n\n\n\nUn ejemplo: c\u00f3mo hicimos esto en Mailgun<\/h3>\n\n\n\n
La API principal de \/messages en Mailgun est\u00e1 gestionada por un servicio al que llamamos influx. Este servicio incorpora tanto mensajes HTTP como SMTP en nuestro sistema y se comunica con pr\u00e1cticamente todos los dem\u00e1s servicios de nuestro paquete de servicios de env\u00edo de mensajes.<\/p>\n\n\n\n
Como resultado, hemos invertido mucho en nuestro paquete de pruebas funcionales y hemos modelado nuestro entorno de producci\u00f3n en el c\u00f3digo para esta parte tan p\u00fablica de nuestro cat\u00e1logo de servicios. Hemos creado m\u00e1s de 700 pruebas, la mayor\u00eda de las cuales son funcionales y se completan en unos seis minutos en un equipo local.<\/p>\n\n\n\n
Muchas de estas pruebas se a\u00f1adieron durante las sesiones de depuraci\u00f3n o diagn\u00f3stico y luego se incorporaron a nuestro paquete de pruebas. Si se necesita un nuevo escenario, se a\u00f1ade al paquete funcional y sirve de protecci\u00f3n frente a futuras regresiones.<\/p>\n\n\n\n
Reflexiones finales<\/h2>\n\n\n\n
El verdadero coste del desarrollo de software reside en el mantenimiento y diagn\u00f3stico del c\u00f3digo. Por eso, prepararse para el \u00e9xito mediante la creaci\u00f3n de un paquete de herramientas que puedas usar para disminuir el tiempo de resoluci\u00f3n justifica el tiempo y el dinero adicionales.<\/p>\n\n\n\n
Esa inversi\u00f3n inicial seguir\u00e1 dando sus frutos a medida que avance el proyecto.<\/p>\n\n\n\n
\u00bfTe ha gustado nuestra visi\u00f3n sobre c\u00f3mo encontrar y diagnosticar errores de software? Si quieres m\u00e1s contenido como este, no olvides suscribirte a nuestra newsletter.<\/p>\n\n\n