Jesús L.C. – Apuntes de un aprendiz

Ultimamente casi todo el mundo habla de testear, de hacer refactoring, de mejorar,.. parece que intentar hacer las cosas bien se está poniendo de moda. Y eso mola.

Hoy me gustaría hablar sobre mi experiencia haciendo testing unitario y sobre los mitos que creo que hay detrás de todo esto de los tests. Eso sí, esto son opiniones personales basadas en mi experiencia por lo que no pueden traducirse a todos los escenarios, por eso me encantaría conocer tu visión en los comentarios.

Vamos a por los mitos:

Los test incrementan la calidad del código

Yo creía que los beneficios de hacer test unitarios eran mejorar la calidad de nuestro código. A medida que he ido aprendiendo, me he dado cuenta de que no es así. Los unit test no chequean la calidad de nuestro código, ya que podemos tener test unitarios y que nuestro código no tenga calidad ninguna. El hecho de tener 100% de cobertura solo nos garantiza que los tests hayan pasado por ahí, no que se esté comprobando/asertando ese trozo de código.

Lo que incrementa la calidad de nuestro código es: que escribamos teniendo en mente los principios SOLID, que intentemos aplicar Object Calisthenic, que intentemos que nuestro código se lea como “prosa”, que los métodos y las clases sean relativamente pequeños, que usemos un estándar de código,… en resumen que nuestros compañeros puedan entender nuestro código fácilmente.

En resumen:
Nuestro código mejorará en calidad si:
– Si usas nombres apropiados
– Nuestros compañeros puedes entender nuestro código

Es cierto, estos factores son importantes y no tienen nada que ver con los test, pero son los que junto con los test hacen que tu código sea mucho más mantenible.

El software testeado está libre de bugs

No me gustan los bugs y creo que no soy el único, aunque a veces… a veces hay algunos bugs que cuando encontramos la solución  y vemos que todo vuelve a la normalidad pues nos hacen sentir un “killer del código” por un minuto.

Al fin y al cabo, los test unitarios validan la “salida esperada” de los métodos, pero eso no significa que queden huecos sin testear, comportamientos no esperados o lo que sea.

Por todo esto, debemos tener en cuenta que el testing unitario es importantísimo, ya que nos proporciona un arnés para poder refactorizar. Pero no hay que olvidar el testing exploratorio, las pruebas manuales y lo más importante, estar preparado para que cuando los bugs ocurra (porque van a ocurrir lo queramos o no) tengamos un sistema para detectarlos rápidamente y para poder desplegar la solución más rápido si cabe.

No me da tiempo de hacer tests

Cuando estamos escribiendo una funcionalidad y para probarla tenemos que: abrir el navegador, hacer login, ir al formulario que queremos probar, rellenar 5/10 campos, pinchar en esos desplegables que se carga por ajax,… ejecutar y comprobar que todo falla o sigue ok… pues no mola

Quizás sería interesante que invirtiésemos un poco de tiempo en hacer un “pequeño script” que haga esa petición, un curl por consola,  un test de Selenium o algo muy básico que haga que no tengamos que perder el foco para comprobar si lo que hemos programado funciona o no.

Los test son opcionales

Implementar una funcionalidad y escribir código son 2 tareas diferentes. Después de todo podríamos escribir una nueva funcionalidad sin escribir ni un solo test y estaríamos aportando valor. Es cierto, pero sería valor a corto plazo, ya que cada cambio empezaría a costar un poco más, cada vez tardaríamos un poco más en desarrollar nuevas funcionalidades hasta llegar a un código difícil de mantener (lleno de ifs, con nombres difíciles de entender,…), donde un bug nos  hace temblar las piernas

Por ello los test son los responsables de que la aplicación esté correcta, si subestimamos la importancia de los test, eso nos hará tener una brecha en la calidad del software. Los test a la larga nos permitirán trabajar a un ritmo sostenible y al mismo tiempo tendremos un sitio donde saber que hace la aplicación (documentación implícita).

Sin lugar a dudas, los test son parte de la funcionalidad, por lo que deben formar parte de la estimación de la tarea.

Todo tiene que estar testeado

Escribir test de muy bajo nivel puede dañar y mucho nuestro proyecto. A ver, es necesario que hagamos test unitarios, que sean rápidos, repetibles e independientes, pero no es necesario que todo tenga un test unitario.

Por ejemplo, tenemos un servicio para hacer login de usuarios: si empezamos a refactorizar porque vemos que ese servicio no cumple “Single Responsability Principle”
Si partimos ese servicio en varias clases (una para validar, otra de acceso a datos,…) para así hacer que la responsabilidad sea única por cada clase, no deberíamos testear cada clase por separado. Si ya teníamos testeada la clase inicial y tan solo hemos separado, no es necesario testear estas nuevas clases. ¿o si?

Si pensamos en el login como en una caja negra, vemos que tenemos tests para comprobar todos los casos y si ahora sólo hemos refactorizado (sin cambiar la funcionalidad). Eso sí, si añadimos funcionalidades a estas nuevas clases entonces sí tendremos que testear esa nueva funcionalidad, pero solo esa.

La idea detrás de esto es no acoplarnos a los test y tener libertad para refactorizar sin que un pequeño cambio haga explotar por el camino 1000 test distintos porque tenemos los test demasiado unidos al código