Vale, después de lo pesado que me he puesto con este tema por fin te has convencido de las ventajas de usar test automatizados. Pero ¿por dónde empezar?
¿Acaso debo parar a todo mi departamento de desarrollo, dejar de sacar nuevas funcionalidades, ignorar los posibles fallos detectados y ponerles a escribir tests como si no hubiera un mañana? Mmm, no. Creo que eso sería una locura.
Introducir una cultura de pruebas automatizadas en un equipo de desarrollo ya asentado no es fácil. Si además les pedimos que aparquen su trabajo y se pongan con la titánica tarea de añadir tests a una aplicación ya monstruosamente grande les vamos a perder para siempre.
En lugar de eso ¿por qué no empezar poco a poco?
Pruebas automatizadas para los fallos detectados
Una forma de empezar con los test podría ser con los bugs. Cuando al equipo de desarrollo le llegue el aviso de un fallo que hay que corregir se puede empezar creando un test que reproduzca el fallo.
Supongamos un software que genera un fichero XML a partir de los datos de una tabla. Nos informan de un fallo que se produce cuando la tabla contiene un determinado carácter, por ejemplo una ‘X’. La presencia de este carácter ‘X’ provoca que no se genere correctamente el XML.
El primer paso sería crear un test automatizado que reproduzca las condiciones del fallo.
El test sería algo así:
“Si los datos contienen el carácter ‘X’ comprobar que se genera el XML correctamente”
Está claro que al ejecutar el test se producirá un error porque ese carácter da problemas.
A continuación procedemos a solucionar el bug. Por ejemplo, haciendo que nuestro software elimine el carácter problemático cuando lo encuentre.
Probamos el test y, esta vez, pasará sin problemas.
¡Ya tenemos nuestro primer test! Gracias a él podemos estar seguros de que ese problema no va a volver a aparecer. Y así podemos ir añadiendo nuevos test con los nuevos fallos que nos vayan notificando.
Pruebas automatizadas para nuevos desarrollos
Otra oportunidad para la introducción de test son los nuevos desarrollos que nos soliciten.
Imaginemos que nos solicitan que un usuario pueda modificar la dirección de envío de un pedido en una tienda online.
El primer paso sería describir el comportamiento de nuestra aplicación con unos test. Podríamos crear por ejemplo:
- “El usuario logueado puede cambiar su dirección de envío”.
- “El usuario logueado no puede cambiar su dirección de envío si ésta está incompleta”.
- “No permitir el cambio de dirección de envío si el envío ya ha salido.
- “No permitir cambiar la dirección de envío si el usuario no está logueado”.
Como se puede ver, solo con ver estos test ya podemos hacernos una idea de cómo funciona la aplicación.
Ahora tocará empezar a escribir el código para que los test funcionen correctamente.
Pruebas automatizadas para mejorar el código
No nos engañemos, son pocas las ocasiones en las que un equipo de desarrollo tiene la oportunidad de modificar código simplemente “para mejorarlo”.
Pero cuando esta oportunidad llega también podemos aprovecharla para introducir nuevos test.
En este caso partiremos de una situación “buena”. Crearemos unos test para comprobar que todo funciona correctamente y los test deberían funcionar correctamente.
De esta forma podremos estar (casi) seguros de que las modificaciones que hagamos no romperán nuestra aplicación.
¿Y el truco?
El truco está en que depende de cómo de malo sea el código con el que tenemos que trabajar esto puede no ser nada fácil. Si el código está muy acoplado puede no ser nada fácil. Pero seguro que será un trabajo que, a corto/medio plazo, nos compensará.
¿Test unitarios o de integración…?
La eterna pregunta ¿empiezo por test unitarios (que consiste en probar las clases o bloques de nuestra aplicación de forma aislada), de integración (con los que probamos si las piezas trabajan bien juntas) u otro tipo.
Este tema da para un largo artículo y un buen debate pero me voy a mojar. Yo en el caso de una aplicación heredada (una que ha hecho otra) y que es un desastre empezaría por unos test de alto nivel. De esa forma me aseguraría de que todo funciona correctamente. Una vez esos test estén en marcha iría bajando ya a otros niveles.
¿Empiezo con TDD?
Sí, venga, ¡a lo loco! Este es otro debate que se suele dar ¿TDD (primero los test y luego escribir el código) o primero el código y luego escribimos los test? Creo que TDD puede ser una opción para un proyecto que empezamos desde cero, pero si nuestra aplicación es heredada mejor iría por la opción de código primero (de hecho el código ya existe).