Algunas frases que he escuchado y que en algún momento hasta he dicho (y no estoy particularmente orgulloso):
- El testing no sirve para nada
- Esto es bien simple, no necesita testing
- Que testén los usuarios
- El testing es una pérdida de tiempo
- Testear es improductivo
- Testear es aburrido
Bueno, déjenme decirles algo: todas estas afirmaciones están equivocadas. Sí, incluso la última. Testear tiene muchos beneficios, incluso tiene beneficios no directamente relacionados con el testing. Pero no nos adelantemos.
Tal vez la primera -El testing no sirve para nada- sea una de las más dichas y escuchadas. Esta frase la dice la gente que nunca testeó. No conozco a nadie con disciplina de testing que piense esto.
Otra frase nefasta es la tercera -Que testén los usuarios-. No hay peor cosa que entregarle al usuario que un software plagado de errores. La confianza del usuario es una de las cosas más importantes en un proyecto. Al usuario hay que tenerlo de nuestro lado ya que él/ella es la razón por la cual estamos haciendo ese sistema. La confianza se puede perder en un abrir y cerrar de ojos por un error que lleva 5 minutos eliminarlo. Y cuando sucede esto, volver a ganar la confianza cuesta mucho.
Pero ¿por qué se le tiene tanta idea al testing? y sobre todo por la gente que no tiene disciplina testeadora. Yo creo que es porque el testing nos expone a nuestros errores e inconscientemente tratamos de evitar esto. Y mientras haya errores, obviamente, la tarea no está terminada.
Cómo sería la implementación de una funcionalidad para un programador que no testea disciplinadamente:
- Programación de la funcionalidad
- Probar un par de veces (en el mejor de los casos)
- Deploy
Para cualquier funcionalidad más o menos compleja, esto lleva a que haya un caso que no se consideró en el punto 2 y por lo tanto a un error en el sistema. Entonces:
- Corregir el error
- Probar un par de veces (ahora un poco mejor por el sentimiento de culpa
- Deploy
Seis pasos, suponiendo que el error queda arreglado.
Como sería el mismo ciclo, pero con disciplina de test:
- Programación de la funcionalidad
- Programación del test de la funcionalidad
- Probar la funcionalidad
- Deploy
Cuatro pasos.
Les aseguro que la calidad del producto es mucho más alta y no quedamos pegados con el usuario. El “simple” hecho de programar el test, no hace pensar más. Y ¿tardamos más? Generalmente no, porque no hay que corregir errores ni volver a pasar a producción. Igualmente, sería preferible tardar más que por tratar de sacar el sistema antes, se escape un error se dañe la confianza del usuario.
Herramientas
Bueno, basta de psicología barata. Ahora voy a nombrar algunas herramientas que asisten al testing.
Simplemente voy a nombrarlas, hay mucha literatura en Internet sobre estas herramientas.
Unitarios
Para hacer tests unitarios hay básicamente dos frameworks JUnit y TestNG. El segundo es más abarcativo que el primero.
Integración
Para hacer tests de integración, también hay frameworks que nos facilitan la vida, jMock o Mockito por nombrar dos.
Cobertura
La cobertura de código es sin duda una de las herramientas más interesantes para tener una idea de la calidad de nuestro test. Con esta herramienta es muy fácil saber si se nos escaparon casos en nuestros tests, ya que van a aparecer lineas de código son cubrir. La idea es aproximarse lo más posible a 100%.
El hecho de testar, produce efectos secundario (positivos) en nuestro código:
- Con el tiempo produce métodos más simples: Es más fácil testear métodos cortos y simples, que largos y complejos. Cuando programamos pensando en el testing esto surge naturalmente. El código simple es más fácil de mantener.
- Los tests tienden a mejorar la modularización del sistema, ya que pueden exponer problemas de dependencias entre los módulos. Ej: dependencias circulares.
- Los tests tiene un efecto psicológico en el desarrollador, dándole confianza en su producto y fomentando la motivación. Esto hace que testear sea “divertido”.
Notas finales
El test debe ser tomado con profesionalismo: la tarea no está terminada si no tiene el test correspondiente. Está de más decir que el test tiene que ser de alta calidad.
El test sirve para verificar y descubrir errores cuando estamos programando la funcionalidad, pero más importante aún, es que nos da la tranquilidad de que dentro de 6 meses cuando se realizaron un montón de cambios, nuestra funcionalidad se sigue comportando como esperamos.
Implantar el testing en un equipo no es tarea fácil. Requiere tiempo, esfuerzo y no bajar los brazos. Siempre hay rechazo a algo nuevo. Incluso la gente que reconoce el valor del testing, le cuesta arrancar a testear profesionalmente.
El testing (cómo cualquier otra cosa) no puede ser algo impuesto al equipo; por el contrario, tiene que ser aceptado por el equipo, haciéndole ver los beneficios del testing profesional en el día a día. Bien vale la pena el esfuerzo.
