Medir la cobertura de pruebas con Coverlet en .NET te permite saber qué tanto de tu código realmente estás validando con tus pruebas unitarias. Es una librería gratuita y open source que se integra con Visual Studio, la terminal y otras herramientas para entregar reportes claros sobre líneas, métodos y branches cubiertos.

Esto es clave si trabajas con xUnit, TDD o cualquier estrategia de pruebas en proyectos .NET, porque sin métricas reales no sabes si tus pruebas están protegiendo el código o solo dándote una falsa sensación de seguridad.

Qué librerías de Coverlet necesitas instalar

Coverlet no es una sola pieza, sino un conjunto de paquetes que cumplen funciones distintas. Si creaste tu proyecto con la plantilla de xUnit en Visual Studio, ya tienes una parte del trabajo hecho.

En el archivo de configuración del proyecto de pruebas vas a encontrar Coverlet.Collector preinstalado [0:55]. Si usaste Visual Studio Code u otra herramienta, basta con copiar esa referencia al archivo del proyecto o instalarla por CLI.

Las tres piezas que vas a usar son:

• Coverlet.Collector: viene por defecto con la plantilla de xUnit y recolecta la cobertura durante la ejecución de pruebas.
• Coverlet.MSBuild: se instala desde el administrador de NuGet y permite obtener cobertura directamente dentro de Visual Studio [2:00].
• Coverlet.Console: es una utilidad global de .NET, no un paquete de proyecto, y se instala con dotnet tool install [2:40].

¿Por qué Coverlet.Console da error al instalarlo en el proyecto? Porque no es una librería de proyecto, es una herramienta global de la CLI de .NET. Debes instalarla en tu máquina con dotnet tool install, no como NuGet del proyecto.

Cómo instalar Coverlet.Console como herramienta global

Entra a NuGet.org, busca Coverlet.Console y copia el comando que aparece en la sección de instalación. Lo ejecutas en la terminal de Visual Studio (View, Terminal) y, si ya estaba instalada, te mostrará un mensaje confirmándolo. Si no, verás el flujo de instalación hasta el mensaje de éxito.

Cómo ejecutar el comando de cobertura con dotnet test

Una vez tienes todo instalado, la ejecución es directa. Abres la terminal y corres:

bash dotnet test /p:CollectCoverage=true

Es el mismo dotnet test de siempre, pero con el parámetro CollectCoverage en true. Eso le indica a Coverlet que, además de correr las pruebas, calcule los porcentajes de cobertura y los muestre al final [4:30].

En el ejemplo de la clase, el resultado mostró 10 pruebas pasadas, una omitida y una tabla con los porcentajes de la clase StringManipulation.

¿Qué hace el parámetro CollectCoverage en dotnet test? Activa la recolección de métricas de Coverlet durante la ejecución de pruebas y devuelve una tabla con porcentajes de líneas, branches y métodos cubiertos.

Cómo interpretar los porcentajes de líneas, branches y métodos

El reporte de Coverlet entrega tres métricas distintas y cada una te dice algo diferente sobre la calidad de tus pruebas. En el ejemplo, StringManipulation arrojó 23,95% en líneas, 20% en branches y 60% en métodos [5:00].

A primera vista parecen métricas similares, pero miden cosas muy distintas:

• Líneas cubiertas: el porcentaje de líneas de código que se ejecutaron al correr las pruebas.
• Métodos cubiertos: cuántas funciones de la clase fueron invocadas al menos una vez por alguna prueba.
• Branches cubiertos: cuántos flujos lógicos, if, condiciones y caminos alternativos quedaron validados.

Los métodos suelen mostrar porcentajes altos porque basta con una prueba básica para marcar un método como cubierto. Los branches, en cambio, son la métrica más estricta y la más importante.

Por qué los branches son la métrica más importante

Un método puede tener varios caminos posibles. Tomemos TruncateString como ejemplo: tiene un primer if, un segundo if y un return final. Eso significa tres flujos posibles dentro del mismo método [6:10].

Si solo pruebas uno de esos caminos, el método aparece como cubierto, pero los branches siguen bajos. La única forma de subir esa métrica es leer el código, identificar cada condición y escribir pruebas específicas para cada flujo.

Por eso, cuando trabajas con TDD o con cobertura como criterio de calidad, el porcentaje de branches es el que mejor refleja qué tan robustas son tus pruebas. Un 60% en métodos puede convivir con un 20% en branches, y eso significa que tu código tiene huecos lógicos sin validar.

Con Coverlet ya configurado y ejecutándose, el siguiente paso es jugar con sus parámetros de configuración para ver cómo cambian los reportes. ¿Has medido cobertura de branches en tus proyectos .NET? Cuéntame en los comentarios qué porcentaje manejas hoy.