Junit Test and code coverage

Para comprender el concepto de calidad y cobertura de código o “code coverage”, debemos de hablar de pruebas unitarias o “unit tests”. Para lograrlo se va a hacer uso de un lenguaje coloquial y accesible, incluso para personas que no poseen habilidades de programación. No obstante te puedes pasar por el siguiente enlace y seguir documentando.

Introducción

A medida que vamos desarrollando un proyecto, se incrementa la posibilidad de introducir de forma accidental diversos errores. Esto se produce principalmente porque somos humanos.
Una práctica habitual es descomponer nuestro código en partes pequeñas que seamos capaces de probar, llamadas funciones o métodos. Podemos ver estas funciones o métodos, en adelante funciones, como pequeñas acciones que sumadas realizan una acción mayor, o simples cajas que forman parte de otra caja. Un ejemplo, podría ser, un programa, calculadora (caja), que permite realizar operaciones simples de cálculo (suma + resta + multiplicación + división). De esta forma estas operaciones serán cajas simples que forman parte de la gran caja.

Programa => “La gran caja”

Operaciones => “cajas simples”

A este concepto, se le conoce como divide y vencerás o descomponer un gran problema en pequeños problemas para encontrar una mejor solución.

Teniendo en cuenta lo anterior, podemos encapsular las funcionalidades (construir cajas pequeñas), lo que nos permite diagnosticar y resolver los problemas (errores) con mayor facilidad.

Ahora vamos a trabajar en encontrar y solventar los problemas que detectemos. Para conseguirlo vamos a hacer uso del concepto de “unit test” o test unitario, en adelante test (Probar las cosas para saber que funcionan correctamente).

Ejemplo teórico

Mi abuela tenía una calculadora para realizar los cálculos necesarios para vender su queso, una o dos veces por semana.
Este ejemplo resulta muy simple, pero pongamos que mi abuela se equivoca, y realiza una división por 0, cuál es el resultado correcto.
Los test, tienen como principal misión evitar estos errores, y garantizar un programa eficiente.

¿Qué es un test?

Un test es una prueba, que tiene como objetivo detectar fallos en nuestras funciones durante el proceso de desarrollo.

Mientras desarrollamos nuestro código, hemos de desarrollar de forma paralela los diferentes test para tener la certeza que nuestro programa es una solución robusta (eficiente).

¿Para qué sirven los test?

Pensemos en un robot, bueno tal vez mi abuela eso no lo entiende, pero si la persona mayor detrás del visillo, que vigila el correcto funcionamiento de nuestro programa (calculadora), que para mi abuela servía para realizar los cálculos cuando vendía su queso. Bueno ese robot, (persona detrás del visillo), es el encargado de analizar el resultado de nuestras funciones (cajas), tanto cuando los parámetros de entrada (elementos) son correctos, como cuando estos no lo son, y la respuesta de la caja es la incorrecta. Es decir tenemos todo controlado, “La abuela del visillo lo tiene todo controlado”.

La pregunta que te harás en estos momentos es por qué se producen estos errores, éstas son las principales causas:

  • Factor humano. Todos somos humanos menos yo.
  • Prisas. “Lo tienes que tener terminado para ayer”.
  • Exceso de seguridad en uno mismo. Nos creemos “Superman”. ¡Superman no!, pero Lobezno, sí que soy.
  • Complejidad del problema (caja) a resolver.

¿Qué es la cobertura de código?

La cobertura de código, o code coverage, es un término que se usa para describir cómo son de efectivos nuestros unit tests y que desemboca de alguna manera en la calidad de nuestro código. De esta forma, haremos diferentes pruebas con distintos parámetros de entrada, comprobando que el resultado es el esperado. Esto hará que la ejecución de los distintos test, recorran código (partes de la caja) que no sucedería en el caso de que fueran siempre los valores correctos o esperados.
En resumen la cobertura de código es el % del código, que los test, durante su ejecución recorren, con el fin de tener todo el código desarrollado testeado.

Resumen

Los test requieren de un tiempo adicional de desarrollo, pero es un coste de tiempo que se paga sólo una vez. En cambio, probar manualmente el código de nuestro proyecto, testeo tipo mono, tiene un coste de tiempo que debemos pagar cada vez que realizamos cambios.

Para realizar este proceso, junto a maven, podemos integrar jacoco, y este nos genera los informes de resultados de resultados de cobertura.

En el siguiente enlace podrás ver un pequeño ejemplo, de la calculadora de mi abuela ;), con los plugins configurados y donde sólo debes lanzar “mvn clean test y acceder a target/jacoco-out/index.html”

¡¡¡ Sed buenos, disfrutad programando y recuerda que el siguiente post está a medio cocer. 😉 !!!!.