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
Conclusiones
Esto son los mitos que más me he ido encontrando, pero seguro que no son los únicos. Y tú, ¿que opinas del testing?¿es necesario? ¿te has sentido identificado con alguno de los mitos? ¿hay algún mito que quieras compartir?
Jesús L.C. - Apuntes de un aprendiz 
Totalmente de acuerdo con estos mitos, pero discrepo ligeramente en el primero. Aunque no se puede tomar los test como la panacea para mejorar la calidad del código, hacer test unitarios hace que involuntariamente se tienda a crear clases y funciones con un comportamiento bien definido y bajo acoplamiento, especialmente si hacemos TDD, aunque como bien dice hay otros muchos aspectos que nos se tienen en cuenta en el testing y son necesarios para una buena calidad.
Me gustaMe gusta
Muchas gracias por comentar, es cierto que como dices hacer test unitarios ayuda, pero no lo es todo. Por ello el mito que quería desmontar es que no sólo es necesario tener test, sino que los test ayudan a:
– nombrar mejor, porque con test cambiar un nombre es sencillo
– separar responsabilidades: porque podemos separar clases y ver que todo sigue funcionando
– …
pero tenemos que querer hacer estas cosas. Por eso decía que no son solo tests, es «un poquito más»
Me gustaMe gusta
Muy buen post jesuslc, yo trabajo
Me gustaMe gusta
En un departamento de calidad y lo que hemos aprendido es que la calidad se construye entre todos. Tanto desarrollo como el equipo de pruebas. Es importante hacer pruebas unitarias, son el primer nivel para detectar fallos unitarios. Tan bien ayudan a educar y tener una visión de la construcción del sw.
Para ello es recomendable también realizar análisis estático de código por lo que comentabas (mismos estándares, criterios, menos código duplicado….).
Después de este tipo de pruebas hay que realizar pruebas de integración y funcionales para verificar que la aplicación haga lo que tiene que hacer…
Me gustaMe gusta