Voy a hacer este post para expresar una opinión que tengo hace mucho tiempo, ya que llevo años escuchando la misma cantinela. “Cuál es el porcentaje de código?” y estoy cansado de explicar lo mismo una y otra vez. El porcentaje de código no importa un cagarro.
Voy a escribir este post, argumentando y poniendo ejemplos para que así se lo puedes enviar a tu jefe en vez de intentar discutir con él temas que posiblemente no entienda.
Índice
1 - El Alto porcentaje es un engaño
Voy a empezar por lo más obvio, y personalmente, pienso que los desarrolladores no hacemos lo suficiente para evitar esta situación.
El alto porcentaje de la cobertura de código, no sirve para nada, no mide absolutamente nada. El único motivo por el que ese número existe es para poder reportarlo a gente que no tiene ni idea de lo que es, y básicamente necesitan ver un número lo más cercano a 100 para poder ser felices.
En parte entiendo que simplemente lo demos y ya, porque a la larga, cuesta más explicar porque es una medida inutil que simplemente dar el número. Y esto lo digo desde la experiencia, da igual cuantas veces lo expliques, o que incluso pruebes que puedes cubrir un código al 100% sin testear absolutamente nada.
public void Test(){
FooService service = new FooService();
int result = service.Execute(1);
Assert.Equal(5, 3+2 )
}Este test, es clarísimamente una exageración a lo absurdo, y vas a decir que ese test no pasa la revisión de código?, ¿Que no?, ¿Quieres apostar? Si le digo a un compañero, “hey revisame la PR “ y 10 segundos después está aprobada, ¿crees que va a darse cuenta de ese test?
Pero bueno, volamos, este ejemplo te permite coger la idea, ejecutas algo, el código va por todas las líneas y luego simplemente compruebo cosas random. El calculador de % de código nos va marcar que hemos cubierto el 100%, y no la lógica, que es lo que debería calcular.
Pero bueno es lo que hay, también tengo que decir, que igual que tener un 100% cubierto no prueba nada, tener un 0% prueba que no tienes ni un test.
2 - Falsa sensación de seguridad
Indicar un alto porcentaje lleva al engaño ya que podemos decir que tenemos un 95% testeado, y así lo dice la maquinita. Entonces si tenemos un bug? Va a estar en ese 5%? Posiblemente eso es lo que piense la cadena de mando, pero lo más probable es que el bug que ha petado producción, y nos tenga despiertos un día a las 2am, haya pasado en ese 95% que “Si” que está testeado.
Así que esto es simplemente otra prueba de que el porcentaje no sirve para nada. Para poner un ejemplo real es cuando tenemos una dependencia, y por lo que sea la dependencia falla, o nos devuelve un resultado inesperado por un bug que tenga dicha dependencia. ¿Qué hacemos ahí? ¿Estamos cubriendo ese caso? Lo más probable es que NO.
Pero, espera, si estamos cubriendo el 100% del código, ¿Cómo puede haber un error?
3 - El impacto en la productividad
Tener un 100% de code coverage es simplemente estúpido, no estoy diciendo que no haya ninguna pieza de software que no tengamos que cubrir completamente, todas las aplicaciones tienen “core” o partes muy muy importantes que es impepinable cubrirlas, y esta bien que así sea. Pero en programación todo son tradeoffs que se llaman, osea, que todo tiene pros y contras.
Cubrir el 100% es normalmente una pérdida de tiempo, no porque no sea útil, sino porque lleva tanto tiempo testear bien el 100% que gastarías más tiempo creando tests que en el resto del proyecto. Y allá cada uno con su tiempo y dinero. Pero para tener una suite completa es para lo que tenemos diferentes tipos de tests (unit, componentes, integración, end to end, UI, etc) y AH! Oh! SPOILER! Los test end to end o los de interfaz de usuario, o incluso los de integración, no están incluidos en la cobertura de código, pero son igual de importantes que los unitarios… Así que, si tenemos este tipo de tests, ya sabemos que el porcentaje no solo es una pérdida de tiempo sino que además el número no es el número real.
4 - Escribir test relevantes y de calidad
Aquí es donde entra la parte más importante, el equipo que está a cargo, ya bien sea de la funcionalidad o del cambio de código. Y por qué digo esto? Porque el código lo escribe uno, pero lo revisan varios. Tener test de baja calidad no es culpa del que los escribe, sino del que revisa.
Hay mucha gente, y yo lo he hecho en el pasado, que ve una PR de 20 ficheros, donde 5 son tests y como es “grande” la miran por encima y los test ni siquiera los miran. No voy a culpar a nadie, porque todos estamos ocupados, pero os voy a contar un secreto. Hacer esta práctica, la de ignorar los test en la PR nos lleva a un final, bugs en producción, así que mi recomendación es que todos los dias tengas 2 slots de 30 minutos cada una para revisar códgio, las mias son a las 9am y después de comer.
Como software engineers tenemos que asegurarnos que todo lo que pasa por nuestras manos está en un mejor estado de lo que estaba antes de llegar a nosotros y eso también incluye la revisión de código. Debemos asegurarnos que los test que estamos comprobando cubren “TODO” lo que la persona ha creado. Sobre todo las partes de lógica de negocio.
Una práctica que me gusta a mi es la siguiente. Cubrir todas las salidas. Vamos a imaginarnos que estamos testeando un método el cual llama a una dependencia.
public Article InsertArticle(string content, string title, int authorId)
{
if (!_authorRepository.IsValid(authorId))
{
throw new Exception("Author not valid");
}
int aritcleId = _articleRepository.Insert(content, title, authorId);
return GetArticle(aritcleId);
}En este caso en concreto tenemos dos salidas, la excepción y el propio retorno del método.
Como punto de partida el reviewer debe asegurarse de que ambas salidas están testeadas y todo funciona como se espera. Además, eso generará que este código en concreto esta testeado al 100%, tu jefe lo mismo te da una palmadica en la espalda.
Pero realmente lo ideal, y para mi obligatorio, sería tener algún test adicional, porque para eso tenemos en nuestro framework de testeo de cabecera (el que más te guste) formas de reutilizar tests con diferentes parámetros. Para cubrir muchos escenarios, por ejemplo, qué pasa si “content” es nulo? Ahora en C# tenemos nullable, pero hasta hace un par de años no, entonces debemos tener un test, en este caso de integración, que compruebe que pasa si el valor es nulo, porque spoiler, en la base de datos ese valor va a ser obligatorio, pero en el código, por lo que sea, nadie comprueba que los sea y solo se asume.
Estos test adicionales, NO suben el porcentaje de cobertura de código ni un 1%, entonces? ¿Para qué voy a hacerlos si mi jefe no va a ver el beneficio en ellos? La respuesta es clara, porque te preocupas por el software que escribes, y no quieres que tenga bugs en producción, y con tests adicionales, es posible que no sigas cubriendo todos los edge cases, pero al menos, la gran mayoría.
Así que para poder decidir cuando una suite de test es completa, no vale con el numerito, hay que comprender los tests, hay que comprender el código y por supuesto, debes ejecutar la suite en tu máquina y asegurarse de que todo funciona como es debido.
Y como has podido ver a lo largo de este post, el porcentaje no importa lo más mínimo, no es una medida que mida absolutamente nada, y además, en la gran mayoría de casos, es un numero erroneo.
