Cuando ejecutas Coverlet por primera vez, el porcentaje de cobertura que obtienes puede engañarte. Mide código que no necesitas probar, como clases de consola o utilidades de presentación. Aquí aprendes a filtrar esos archivos con los parámetros Include, ExcludeByAttribute y ExcludeFromCodeCoverage para que tu reporte refleje solo la lógica de negocio en .NET.

Por qué tu cobertura inicial no es realista

Al correr dotnet test /p:CollectCoverage=true, Coverlet calcula la cobertura de todo el módulo referenciado, incluyendo clases que solo sirven para correr la aplicación. [00:36]

En el ejemplo, la librería String Manipulation contiene la clase String Operations (la lógica de negocio) y también la clase Program, que únicamente imprime mensajes y captura input del usuario. Esa clase Program no debería contar para tu cobertura porque no hace parte del comportamiento que vas a probar.

¿Qué mide Coverlet por defecto? Mide todo el módulo referenciado en el proyecto de pruebas, sin distinguir entre lógica de negocio y código de infraestructura. Por eso necesitas configurarlo.

La pregunta clave es: cómo le dices a Coverlet que ignore Program y se enfoque solo en String Operations.

Cómo filtrar por namespace con el parámetro Include

El primer método es usar el parámetro Include directamente en el comando. Le indicas a Coverlet qué namespace quieres medir y descarta el resto. [01:35]

El comando se ve así:

bash dotnet test /p:CollectCoverage=true /p:Include="[]StringManipulation."

Con esto Coverlet revisa cada clase del proyecto y aplica esta lógica:

• Si la clase pertenece al namespace StringManipulation, calcula su cobertura.
• Si la clase no pertenece a ese namespace, la omite por completo.
• El reporte final solo incluye lo que realmente quieres medir.

En el ejemplo, IFileReaderConnector y StringOperations sí están dentro de ese namespace, mientras que Program no. Resultado: Program queda fuera y el porcentaje de cobertura sube de inmediato porque ya no se diluye con código irrelevante.

Cómo excluir clases con ExcludeFromCodeCoverage

La segunda opción te deja la decisión en el código, no en el comando. Es útil cuando quieres marcar de forma permanente qué archivos deben ignorarse.

Qué es el atributo ExcludeFromCodeCoverage

Es un atributo del namespace System.Diagnostics.CodeAnalysis que Coverlet reconoce por defecto. Lo agregas encima de la clase o del método que quieres excluir. [03:05]

csharp using System.Diagnostics.CodeAnalysis;

[ExcludeFromCodeCoverage] public class Program { // código de consola }

La flexibilidad está en el alcance:

• A nivel de clase: excluye todos los métodos y propiedades de esa clase.
• A nivel de método: excluye solo esa función específica.
• Puedes combinarlo: marcas la clase y dejas un método sin atributo si quieres medirlo.

Cómo activarlo desde el comando con ExcludeByAttribute

Una vez marcadas las clases, ejecutas Coverlet con un parámetro distinto:

bash dotnet test /p:CollectCoverage=true /p:ExcludeByAttribute="ExcludeFromCodeCoverage"

Le estás diciendo: ignora todo lo que tenga ese atributo y mide la cobertura del resto. [04:05]

¿Cuándo conviene usar Include y cuándo ExcludeByAttribute? Usa Include cuando quieras un filtro temporal o por proyecto sin tocar el código. Usa ExcludeFromCodeCoverage cuando la decisión de excluir sea permanente y forme parte del diseño.

El resultado es muy parecido al del primer método, pero la responsabilidad vive en el código fuente.

Qué porcentaje de cobertura deberías buscar

Una vez tienes el reporte limpio, el siguiente paso es subir la cobertura escribiendo pruebas para cada flujo de tus funciones de negocio.

La meta razonable está entre 80% y 90% de cobertura. Con ese rango garantizas calidad sin caer en la obsesión de cubrir cada línea trivial. [04:55]

El ciclo de trabajo es simple:

1. Escribe una prueba nueva para un escenario sin cubrir.
2. Ejecuta dotnet test con el parámetro de cobertura.
3. Verifica que el porcentaje sube y repite hasta llegar al rango objetivo.

¿Para qué sirve filtrar la cobertura en Coverlet? Para que el porcentaje refleje la calidad real de tu lógica de negocio y no se infle ni se reduzca por código que nunca pensabas probar.

La configuración que acabas de ver prepara el terreno para algo más útil: un reporte visual y completo de cobertura. ¿Qué clase de tu proyecto crees que merece quedar fuera del cálculo? Cuéntalo en los comentarios.