¿Cuantas Unit Tests debe de tener mi proyecto?

Pescar

Una pregunta muy común entre los programadores que se inician en el camino de calidad en sus proyectos es: ¿cuantas pruebas necesito para garantizar la calidad?. La respuesta es la mas molesta que puedes recibir de un programador: depende. No hay un numero mágico de cobertura o numero de pruebas que garantice que tu sistema esta libre de bugs. A continuación te explico como abordo esta problemática.

¿Por donde empiezo?.

La codificación de pruebas inicialmente busca asegurar el estado de los flujos críticos de tu aplicación. El primer paso antes de codificar, es conocer tu código. Debes de poder diferenciar que error es costeable y que error no. Por ejemplo:

Eres el encargado de mantener la pagina de ventas de la empresa. Los posibles clientes se registran en la web, crean y editan su perfil, después realizan sus compras. Tanto el registro exitoso de un nuevo cliente, como el finalizar la compra son flujos críticos para la empresa. El fallo en alguno de estos dos se refleja en perdidas. ¿Que pasaría si falla la edición de perfil del usuario?, digamos que no pueden cambiar la imagen de perfil o que se pierde el día registrado de la fecha de nacimiento del cliente. Si bien, son errores, hay que repararlos y asegurarnos que funcionen. Estos no son objetos de tanto interés. Podríamos omitir o postergar la codificación de pruebas, probar con menos frecuencia o simplemente revisarlo mas adelante.

Ya conozco los flujos críticos, ¿y luego?.

Es necesario que sepas que cualquier tipo de pruebas que quieras codificar debe ser parte de una estrategia integral. Una matriz de pruebas solo de un tipo sera ineficaz, lo que necesitas es diversidad. Si no conoces todos los tipos de pruebas que puede haber, puedes leer el Bestiario de pruebas automatizadas que estaré preparando próximamente. La idea de tener mucha variedad de pruebas en nuestro arsenal es atrapar cada tamaño de bug. Imagina que los errores en nuestra aplicación son peces, de diversas formas y tamaños. Para atraparlos tienes a tu disposición una serie de redes, cada uno pensado para atrapar algo en particular. La única estrategia viable para atraparlos a todos, es usar todas tus herramientas.

  • Peces pequeños (Pruebas unitarias): Las pruebas unitarias, la unidad básica de pruebas te sirve para atrapar los bugs mas pequeños. La mayoría de estos errores ocurren en tiempo de codificación.
  • Peces medianos (Pruebas de Integración): Los bloques de código en nuestro sistema se conocen y se comunican entre si. Muchos errores ocurren en la mala interacción de estos componentes. Este tipo de bugs son mas fuertes, es un poco mas difícil atraparlos. Por eso necesitamos redes mas grandes y firmes llamadas pruebas de integración. Estas son mas difíciles de producir y de operar, requieren de mas tiempo por parte del programador en turno.
  • Peces grandes (Pruebas de estrés, pruebas de aceptación, pruebas de regresión, pruebas de concurrencia). Siempre existirá la posibilidad de que bugs mas difíciles de reproducir o detectar se te cuelen, es inevitable. Al igual que con las pruebas de integración, si el pez crece entonces también lo harán nuestras armas. Vas a requerir de un set especial de pruebas, que validen distintos aspectos de tu aplicación (estres, concurrencia, regresión y aceptación). No es necesario ejecutarlas siempre, quizá no llegues a necesitarlas. Es bueno que sepas que existen.
  • Ballenas(Pruebas manuales). Las pruebas automatizadas no quitan la necesidad de probar manualmente, es el ultimo recurso a tu disposición. Probar manualmente es caro, toma tiempo y no es una acción repetible.  No es algo que se quiera hacer siempre, la labor del Tester debe ser para localizar grandes errores que otros mecanismos no pudieron atrapar. Estamos hablando de bugs muy gordos y complicados.

Concéntrate en la calidad de tus pruebas, no en la cantidad.

El numero de pruebas en tus proyectos no es importante, con que tengas un puñado de pruebas fiables en las que puedas confiar siempre, con eso es suficiente. Claro, el numero ira variando. Las pruebas no son estáticas, dependiendo del flujo de tus sistemas el total subirá o bajara. Algunas pruebas se romperán, tendrán que ser reescritas o simplemente dejaran de tener importancia. Por lo general, a partir de los flujos críticos de tus pruebas ira surgiendo la necesidad de construir pruebas adicionales o complementarias. Imagina los tallos de un árbol. Un pequeño tallo surge de un tronco grueso y con el tiempo este va creciendo hasta llegar al grueso del original. Así sucederá con tus sistemas.

Conclusiones.

No tengas miedo en mejorar la calidad de tus programas. Cualquier intento por producir mejor código, es mejor que ningún intento. Esto es un ensayo error, algunas cosas te van a funcionar, otras no. Todo es cuestión de seguir intentándolo. Cuéntame, ¿cual ha sido tu experiencia con el testing?.

 

Autor Imagen: Tony Alter