¿Qué es eso de los test automatizados?

Sí, yo hablo mucho. Y una de las cosas que repito hasta la saciedad es el tema de los test automatizados.

A ver si te suena esto:

Entras en el formulario. Rellenas todos los datos correctamente (nombre: Gorka, apellidos: Urrutia). Envías el fomuario ¡Ay, que el nombre de ese campo estaba mal! Recargas el formulario. Vuelves a rellenar los datos de cualquier manera (nombre: aaaa, apellidos: bbbb). Vuelves a enviar el formulario ¡Ay, que me faltaba el campo en la tabla!…

Si este (o algo similar) es tu día a día sigue leyendo.

No hay software sin fallos

Cuando creamos software, por cada pequeño cambio que hagamos, tenemos altísimas probabilidades de cometer errores.

Para evitar estos errores lo habitual es probar a mano todos los cambios que hemos hecho. Pero probar las cosas a mano supone mucho tiempo y dedicación. Así que solemos probar lo mínimo imprescindible.

Inconscientemente tendemos a pensar que lo que antes estaba bien no tiene por qué fallar. Como, además, probarlo todo nos da pereza procuramos evitar la revisión completa.

¡Y ahí es donde se nos cuelan los errores!

Los desarrolladores hacemos trampa al probar nuestras aplicaciones

Yo hago trampa, tú haces trampa, ella hace trampa, nosotros hacemos trampa…

Reconócelo, cuando pruebas tu aplicación sabes dónde va a fallar y lo evitas. Para hacer tus pruebas a mano esquivas todas aquellas cosas que sabes (o sospechas) que podrían provocar un fallo. Eso es hacer trampa.

¿Te suena esta situación? Tienes a un tercero probando lo que has hecho y piensas «mierda, no metas acentos que va a fallar», «noooo, estás poniendo un nombre demasiado largo». Y entonces empiezan las excusas: «¿es que sabes lo que pasa? …». Eso es que estás haciendo trampas. Y lo malo es que seguimos con estas trampas casi hasta el final.

Probar todo supone un gran esfuerzo

El problema de hacer cualquier desarrollo o cualquier cambio es que probar que todo esté bien de manera manual es un engorro.

He descrito en los primeros párrafos la forma de comprobar el funcionamiento de un formulario. Por cada prueba que vamos haciendo la calidad de éstas va disminuyendo porque nos aburre estar probando lo mismo una y otra vez (por ejemplo vamos dejando los campos no imprescindibles vacíos).

Bueno ¿y cuál es la solución?

Para evitar errores y probar toda nuestra aplicación sin intervención humana y de forma relativamente rápida podemos usar los test automatizados.

Un test automatizado nos permite probar una parte de la aplicación sin que tengamos que estar rellenando formularios o realizando esas aburridas acciones una y otra vez.

Hay muchos tipos de test. Entre otros:

• Test unitarios: son el tipo más básico que existe. Consiste en probar una pieza de nuestro sistema de manera aislada. Por ejemplo sirve para probar una clase.
• Test de integración: está bien tener todas las piezas probadas. Pero hay que asegurarse de que las piezas funcionan bien juntas. Para eso están los test de integración.
• Test end-to-end: son los test que simulan la interacción del usuario y prueban que la aplicación funciona de la forma esperada.

Existen multitud de herramientas para probar de forma automática una aplicación. En otros artículos contaré qué herramientas usamos en Solvent. Por ir adelantando un poco comentaré simplemente que los test unitarios y de integración los solemos hacer con PHPUnit y los de end-to-end con Cypress. También solemos usar Behat.

¿Y qué aspecto tiene un test de éstos?

El aspecto de los test depende del sistema que utilices pero, a grandes rasgos, es algo como lo que vamos a ver a continuación. Imagina que quieres probar que un usuario puede borrar un pedido de la base de datos:

1. Fase de preparación. Dejas el entorno preparado para que quede en un estado controlado. En nuestro ejemplo habría que crear un pedido en la base de datos para poder borrarlo.
2. Fase de acción. En esta fase del test realizas la acción que quieres probar. En nuestro ejemplo la acción sería borrar el pedido.
3. Fase de comprobación: Esta es la fase en la que te aseguras de que todo ha ido bien. En nuestro caso sería comprobar que el pedido ya no está en la base de datos.

¿Cuántos test necesito?

Leyendo el ejemplo anterior seguro que te has dado cuenta de que harían falta unos cuantos test relacionados:

• Hay que probar qué pasa si el pedido no existe.
• Hay que comprobar que un cliente no borre el pedido de otro cliente.
• Hay que probar que un usuario no logueado no borre el pedido.
• etc.

Y así podrías seguir hasta el fin del Universo. Así que ¿cuántos test necesito? Esa es una muy buena pregunta. Una buena respuesta podría ser «Tantos como necesites para tener la confianza de que todo funciona de manera correcta».

Tú ya estás haciendo test… pero de forma manual

Posiblemente te suene muy exótico esto de los test y que es una cosa que no va contigo. Que no tienes tiempo para perder con estas cosas de frikis.

Si es así tengo una noticia para tí. Sí, tú ya estás haciendo test… pero de forma manual. Estás haciéndolo de la forma difícil, aburrida y propensa a errores. Y lo estás haciendo una y otra vez, y otra vez.

¿No te apetece probar algo diferente?

¿Cuánto cuesta no tener un sistema de pruebas automático?

Ahora que sabes lo que son los test automatizados vamos a ver en la próxima entrega qué supone no tener un sistema de este tipo y hacer las pruebas de forma manual.