Qué significa el porcentaje de cobertura de código

Esto es elemental pero nunca sobra un poco de repetición: la cobertura de código es una métrica INVERSA. Vamos a ver por qué. En la clase de abajo tenemos un solo método que probar: el ToString(). Queremos que nos devuelva el nombre completo del cliente cada vez que se lo invoque.

public class Customer

{

    private string firstName, middleName, lastName;

 

    public Customer(string firstName, string middleName="", string lastName="") 

    {

        this.firstName = firstName;

        this.middleName = middleName;

        this.lastName = lastName;

    }

 

    public override string  ToString()

    {

        string fullName = string.Empty;

 

        if (!string.IsNullOrWhiteSpace(firstName))

        {

            fullName += firstName + " ";

        }

        if (!string.IsNullOrWhiteSpace(middleName))

        {

            fullName += middleName;

        }

        if (!string.IsNullOrWhiteSpace(lastName))

        {

            fullName += " " + lastName;

        }

 

        return fullName;

    }

}

Con la siguiente prueba obtenemos el 100% de cobertura de código:

[Test]

public void ToString_must_return_the_full_name()

{

    var customer = new Customer(

        firstName: "Lucas",

        middleName: "Eugenio",

        lastName: "Ontivero");

 

    Assert.That(customer.ToString(), Is.EqualTo("Lucas Eugenio Ontivero"));

}

Pero si volvemos al método ToString() podremos a simple vista notar esos extraños espacios en blanco concatenados inmediatamente después de firstName y antes de lastName. El método obviamente está mal y lo podríamos descubrir con la siguiente prueba:

[Test]

public void ToString_must_return_the_full_name_even_with_no_middle_name()

{

    var customer = new Customer(

        firstName: "Lucas",

        lastName: "Ontivero");

 

    Assert.That(customer.ToString(), Is.EqualTo("Lucas Ontivero"));

}

Test ‘ConsoleApplication3.CustomerTests.ToString_must_return_the_full_name_even_with_no_middle_name’ failed:
  Expected string length 14 but was 15. Strings differ at index 6.
  Expected: «Lucas Ontivero»
  But was:  «Lucas  Ontivero»
  ——————-^

Entonces ¿para qué nos sirve el valor de cobertura de código?. Bien, si obtenemos una cobertura de código muy baja, como podría ser una por debajo del 30%, esto nos indica que deberíamos redoblar el esfuerzo para crear más pruebas ya que solo una muy pequeña porción del mismo está siendo validada. Por otro lado, un valor alto de cobertura, digamos mayor a un 70%, no nos dice absolutamente nada en el sentido de que no podemos realmente conocer cuantos “caminos” están siendo alcanzados.

Sin categoría

7 thoughts on “Qué significa el porcentaje de cobertura de código

  1. Hola Lucas,

    quería participar con un comentario únicamente con la intención de agregar algo de información que será todavía mucho más aclaratoria respecto a las pruebas y la cobertura de código (una imagen vale más que 1000 palabras).

    Recomiendo el siguiente video (no llega a los 13 minutos) donde se explica muy bien esto y ayuda a comprender mejor la importancia de la cobertura de código en las pruebas unitarias:

    http://channel9.msdn.com/posts/channel9spain/Pruebas-Unitarias-Unit-Testing-con-Visual-Studio/http://channel9.msdn.com/posts/channel9spain/Pruebas-Unitarias-Unit-Testing-con-Visual-Studio/http://channel9.msdn.com/posts/channel9spain/Pruebas-Unitarias-Unit-Testing-con-Visual-Studio/http://channel9.msdn.com/posts/channel9spain/Pruebas-Unitarias-Unit-Testing-con-Visual-Studio/

  2. Por alguna extraña razón, el enlace no parece estar bien.
    Lo agrego a continuación sin el «http://» delante a ver si así sale bien.

    channel9.msdn.com/posts/channel9spain/Pruebas-Unitarias-Unit-Testing-con-Visual-Studio/

  3. Lucas, creo que no entendí tu post pero me excuso porque estoy de vacaciones. Según mi humilde punto de vista, la Cobertura de Codigo (CC) es una extensión a las pruenas unitarias, es decir, no tiene sentido tener un 88% de CC si la mitad de tus pruebas no pasan.

    Ahora bien, es cierto lo que dices que un alto porcentaje de CC no nos indica que se cubran los paths de ejecución más importantes, pero es en este punto donde creo que entra nuestro gran amigo el Sentido Comun y aplicado a la creación de las pruebas correctas, nos dan un 80% de CC bien hecho.

    Salu2 y gracias por los posts de DSLs

  4. Por cierto, en base a las CC, apuntar únicamente un aspecto muy importante y que la gente confunde a veces.

    Cubrir el 100% de la cobertura no implica hacer bien las pruebas. Sólo digo eso.

    Las pruebas deben no sólo cubrir el 100% del código a tratar, sino el 100% de casos dentro del 100% del código, es decir, todas las casuísticas dentro de todas las ramas posibles del código.

  5. @Jorge, gracias por el aporte del video… todavia no lo he visto pero lo voy a hacer cuando llegue a casa. Tu último comentario está justamente en linea con lo que quiero decir en esta entrada. Es claro para mi que hace tiempo que no escribo bien porque parece que mis post no se entienden como yo creo. Pero eso es exactamente lo que quiero decir solo que sin entrar en el tema de la complejidad ciclomática que podría confundir más. Es más, el ejemplo muestra 100% de CC y con una prueba la cual no es suficiente. Para probar completamente el método ToString necesitaríamos 8 pruebas!!! (Esto es demasiado también).

    @Bruno, yo tampoco entiendo bien donde encaja la primera parte de tu comentarios pero está claro que es cierto, no tiene sentido una gran CC si las pruebas no pasan. En cuanto al sentido común, yo quiero darle algunas herramientas de juicio a quienes no saben todavía interpretar los números de CC para que puedan usar su sentido común. Pasa que en mi proyecto tenemos que mostrarle semanalmente métricas como % de CC a los managers que en realidad no las terminan de entender y por lo tanto no pueden usar su sentido común todavía. Por ejemplo, cuando instrumentamos un nuevo assembly que está cubierto en un 20%, en realidad tenemos una mayor cobertura, sin embargo el % de CC baja ya que teniamos un 70% y ahora con este nuevo assembly agregado terminamos teniendo un 66%.

  6. Hola Lucas:

    Entiendo que lo que quieres decir es que un 30% es directamente malo por se muy baja cobertura y que un 70% pues depende, puede ser malo o no en función del número de caminos alcanzados.

    Entiendo que el punto quizás sea que el porcentaje en si mismo no significa nada, cosa en la que estoy de acuerdo. Lo que no entiendo es porque asumes que un 30% es peor que un 70% o mejor que un 0%. ¡El porcentaje de cobertura analizado por sí mismo no significa absolutamente nada!, sea cuál sea su valor, excepto si es muy cercano al 100%.

    Un saludo.

  7. Hola Rodrigo:
    No, tener 30% no es directamente malo porque puede ser un 30% muy bien probado. Lo que quiero decir es que 30% nos dice que el 70% del código no tiene ni una sola prueba (buena/regular/mala) que lo alcance.
    Como bien acordamos, el porcentaje en si mismo no significa nada y por esto mismo yo no puedo nunca asumir que 70% es mejor que 30%.
    Tu conclusión final entiendo que es correcta también. Para mí un 0% significa que no hay pruebas, un 89%-100% _probablemente_ nos indica cierta rigurosidad en la escritura de pruebas para el código (probablemente usan TDD). Entre medio…. quien sabe.
    Un saludo.

Responder a lontivero Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *