Introducción a Testing

Alguna vez les ha pasado que escriben una funcionalidad que va a cambiar la vida del usuario, pero se dan cuenta luego que esa funcionalidad nueva y maravillosa dañó todo.

El objetivo de este artículo es responder dos preguntas fundamentales: ¿Por qué? ¿Por qué son importantes las pruebas en el desarrollo de software?

Y el ¿Cómo?, ¿Cómo podemos nosotros como desarrolladores lograr crear, mantener pruebas, y no morir en el intento?

Muchas veces (y me incluyo), nos preguntamos:

¿Por qué nos molestamos en probar?

¿Por qué es necesario probar el código? Y antes de respondernos esta pregunta, hablemos del primer concepto que podría ser el causante del por qué.

Y es donde nos encontramos con nuestros amigos los bugs, que en su definición se describen como un error o falla en un programa o sistema de computadora que causa que se produzca un resultado incorrecto o inesperado, o que se comporte de manera involuntaria.

Es importante acotar que la palabra inesperado o esperado toma cierto protagonismo en algunos tipos de pruebas que veremos más adelante.

Hay un curso propuesto por Kent C. Dodds, sobre cómo aprender la forma lista y eficiente de probar cualquier aplicación en Javascript (Learn the smart, efficient way to test any JavaScript application) y personalmente me gustó mucho lo que Kent explica en el landing page de este curso.

Cuando un usuario encuentra un bug, este se ve enojado, estresado, o inquieto. Y creo que nosotros mismos como usuarios nos hemos sentido alguna vez de esta manera, e incluso tendemos a ser muy duros cuando encontramos un bug.

Por tanto debemos recordar que los usuarios son muy importantes para cualquier proyecto que estemos desarrollando, de nada sirve un sitio web o aplicación móvil sin usuarios.

Si no hacemos algo al respecto, cada vez que un bug es encontrado, la confianza del usuario se deteriora y podemos incluso perderlos.

Si lo vemos desde otro punto de vista, los bugs causan daño financiero. Pienso que en la mayoría de las empresas dedicadas al desarrollo de software han perdido dinero a causa de bugs.

Si miramos un poco de la historia, hay casos sorprendentes como por ejemplo: En 1996, el cohete Ariane 5 del prototipo de la Agencia Espacial Europea, valorado en US $ 1 mil millones de dólares, tuvo que ser destruido en menos de un minuto después de su lanzamiento, debido a un bug que había en el programa informático de orientación a bordo.

En conclusión,

los bugs son malos!

Debemos hacer algo al respecto

Pues nosotros como desarrolladores tenemos la responsabilidad de garantizar que nuestro código funcione, de no castigar al usuario con bugs, de asegurarnos de que los features nuevos no dañen otras funcionalidades y de que lo que escribamos sea mantenible y entendible a nuestros compañeros de trabajo.

Pero, hay un problema, uno que siempre he escuchado en el día a día, en charlas, conferencias, en platicas con otros desarrolladores, y es que…

Las pruebas toman mucho tiempo y esfuerzo

No tenemos tiempo, ya estamos muy ocupados escribiendo nuevos features. No existe manera de probar todo, la mayoría de pruebas son de hacer click por todos lados y esto toma mucho tiempo y sentimos que estamos perdiendo el tiempo.

Nadie tiene el tiempo para esto, pero nuestro proyecto será probado eventualmente, si no es por nosotros mismos, será probado por nuestros usuarios.

Pero no todo es malo, las pruebas tiene sus ventajas:

• Hacer push de código sin preocuparnos más adelante por romper cualquier otra funcionalidad.

No hay nada como irse un viernes por la tarde sin esa preocupación de que el código que desplegamos en producción pueda romper algo.

• Captura errores que muchas veces no vemos a simple vista: ¿Les ha pasado que tienen todo el flujo de un sitio web definido y de repente aparece un error que nunca se hubieran imaginado qué sucedería? Pues las pruebas ayudan a descubrir esos bugs escondidos.
• Ahorran tiempo.

Y ustedes se preguntarán, si hacer y mantener pruebas toma mucho tiempo y esfuerzo, ¿Cómo es que ahorran tiempo? Pues, las pruebas si ahorran tiempo, tiempo que dedicamos a hacer debugging, a corregir constantemente los bugs, un proyecto sin pruebas tiende a ser poco mantenible, ya que estaríamos corrigiendo bugs y que además estaríamos haciendo pruebas manuales todo el tiempo, entonces si, las pruebas llevan tiempo y esfuerzo pero al final valen la pena.

Ya sabemos por qué son importantes las pruebas y cuáles son las ventajas de aplicarlas en nuestros proyectos, ahora:

¿Cómo funcionan las pruebas?

Es muy sencillo, la metodología de las pruebas consiste en:

• Tenemos nuestro código fuente, que en la mayoría de los casos, arroja un resultado esperado (y es aquí donde vemos de nuevo la palabra esperado).
• Se escriben unas pruebas a nuestro código, estás pruebas posteriormente se ejecutan para luego verificar si fueron exitosas o fallidas.
• Si una prueba es fallida, modificamos y arreglamos la prueba o el código fuente y repetimos el proceso.

De esta manera es que funcionan las pruebas en el desarrollo de software, muchas veces este proceso se realiza antes de hacer push del código o como parte del flujo de trabajo en integraciones continuas.

Ahora, existen varios tipos de pruebas, cada tipo tiene una complejidad y una frecuencia o periodicidad que explicaremos más adelante.

Tipos de pruebas

💻 End to End

Las pruebas punto a punto son aquellas que replican el comportamiento de un usuario. Verifica que varios flujos de usuarios funcionan cómo se espera y puede ser tan simple como cargar una página web o iniciar sesión o escenarios mucho más complejos que verifican las notificaciones de correo electrónico, los pagos en línea, etc.

Las pruebas de punto a punto son muy útiles, pero son de alto costo, pueden ser muy difíciles de mantener cuando están automatizadas.

🎛 Integración

Verifican que los diferentes módulos o servicios utilizados en el proyecto funcionen bien juntos. Por ejemplo, puede probarse un conjunto de funciones que comprenden a un flujo completo, puede ser el checkout en un sitio web. Estos tipos de pruebas son más costosos de ejecutar ya que requieren que varias partes de la aplicación estén vivas y en funcionamiento.

🧪 Unitarias

Las pruebas unitarias son de muy bajo nivel, cercanas a la fuente de la aplicación. Consisten en probar métodos y funciones individuales de las clases, componentes o módulos utilizados. En general, las pruebas unitarias son bastante baratas de automatizar y se pueden ejecutar muy rápidamente mediante un servidor de integración continua.

✏️ Estáticas

Las pruebas estáticas verifican la forma que se escribe código, types o errores de tipado. Por lo general se automatizan con lo que conocemos como linters, que son herramientas que analizan el código para luego corregirlo de ser necesario y están basadas en una configuración o estilo predeterminado.

📃 Aceptación

Existen otro tipo de prueba de más alto nivel y son las pruebas de aceptación, en donde se prueba la aceptabilidad de un proyecto. El propósito de esta prueba es evaluar el cumplimiento del sistema con los requisitos del negocio y evaluar si es aceptable para la entrega.

🔥 Rendimiento

Las pruebas de rendimiento verifican los comportamientos del sistema cuando está bajo una carga significativa. Estas pruebas no son funcionales y pueden tener varias formas para comprender la confiabilidad, estabilidad y disponibilidad de la plataforma. Por ejemplo, puede estar observando los tiempos de respuesta cuando se ejecuta una gran cantidad de solicitudes, o viendo cómo se comporta el sistema con una cantidad significativa de datos.

Las pruebas de rendimiento son por su naturaleza bastante costosas de implementar y ejecutar, pero pueden ayudarlo a comprender si los nuevos cambios degradarán su sistema.

Entonces,

¿Debemos probar absolutamente todo?

Personalmente pienso que no. Los proyectos cambian muy rápido, de repente un cliente desea una nueva funcionalidad que no tiene que ver con lo que esté hecho, lo que funcionaba el año pasado, no funcionará para el siguiente, lo que funciona para un contexto no funcionará para otro, siempre habrá un cambio constante, entonces, sí debemos probar nuestro código, pero no probarlo todo.

El debate de probar o no probar todo también depende del costo de las pruebas.

Vamos a enfocarnos en 3 tipos de pruebas, las unitarias, de integración y punto a punto. Si vemos en la gráfica, las pruebas unitarias tienen menos complejidad (o menos costo), pues son fáciles de lograr, son pruebas que se realizan a funciones que están asiladas y tienden a ser más recurrentes, se suelen escribir muchas pruebas de este tipo, a diferencia de las pruebas de punto a punto, que son mucho más complejas de lograr, puesto que la intención de este tipo de pruebas es simular todo un flujo incluyendo interfaces de usuario, botones, lógica de negocio, etc, por consecuencia se crean muy pocas.

Entonces, debemos tener siempre presente a la hora de agregar pruebas a nuestros proyectos el costo que esta conlleva.

Por lo tanto, lo ideal es ser estratégicos a la hora de probar y hacerse la pregunta:

¿Qué vamos a probar?

Para eso, les voy a contar que puntos son importantes probar.

En primer lugar, definir los casos de uso más comunes de nuestro proyecto, para lograr esto se crea una lista de todos los posibles escenarios, de todas las actividades que un usuario pueda hacer. Una vez que se haya recolectado todos los casos en la lista, es importante tener diferentes opiniones, así que podemos compartir esta lista con los demás miembros del equipo y preguntarnos: ¿Qué otro caso puede un usuario hacer en el proyecto que no esté en esta lista? De esta manera se puede ampliar mucho más las posibilidades de cubrir gran parte de los posible escenarios.

Luego de que se tenga esa lista, lo recomendable es clasificar dichos escenarios según su frecuencia esperada. Esta clasificación debe ser muy acertada, incluso se podría separar en las siguientes frecuencias:

• Extremadamente común: Se estima o presume que el usuario realiza con mucha frecuencia, son los casos que ocurren todo el tiempo.
• Bastante común: Son casos que tienden a ser muy comunes, pero a una menor frecuencia que el anterior tipo.
• Común: El usuario realiza esto de vez en cuando.
• Raro: El usuario rara vez hace cierta actividad:
• Muy raro: El usuario no frecuenta la actividad, casi nunca.

Entonces después de hacer esta clasificación, pasamos a filtrar la lista de casos por el segundo punto importante para saber qué probar.

Y este punto se trata de los escenarios críticos para el negocio. Una vez tengamos las frecuencias en que los usuarios realizan las actividades, clasificamos estos casos basado en la importancia que tiene cada uno sobre las metas de negocio del proyecto. Por ejemplo, si el objetivo de nuestro proyecto es vender productos a través de una plataforma de compras por internet. Para el caso: El usuario compra un artículo, probablemente este caso se priorice en primer lugar, en vez de hacerlo con un caso que no beneficie el objetivo principal, como por ejemplo: El usuario hace un post en el blog.

Los grupos para clasificar los casos son:

• Critico para el éxito del negocio: Es el caso protagonista del modelo de negocio de nuestro proyecto.
• Importante para el éxito de negocio: Tiene mucha importancia, mas no es la actividad principal de negocio.
• Deseable para el éxito de negocio: Qué cosas pueden influir en el cumplimiento con los objetivos principales.
• Irrelevante para el éxito de negocio: Son los casos que no cumplen una función relevante o importante para el negocio del proyecto.

Entonces, ya sabiendo la importancia de por qué probar y de cómo podemos hacerlo, es momento de desarrollar nuestras pruebas.

Espero que esta introducción les haya sido útil, nos gustaría saber, ¿De qué otra forma realizan sus pruebas? y también ¿Qué otros temas les gustaría que escribamos al respecto?

¡Hola! 👋🏻 ¿Ya conoces Monoku? Somos una organización latinoamericana que crea, diseña y desarrolla productos digitales con el objetivo de conectar e impactar de manera positiva la vida de las personas. Te invitamos a que nos conozcas más visitando http://monoku.com y seguirnos en nuestras redes sociales Facebook, Instagram y Twitter.