0
432
Views¿Cómo obtener y analizar todos los archivos de cobertura.cobertura generados en las canalizaciones de CI?
Dada una solución .Net 5 con múltiples proyectos de prueba xUnit, puedo ejecutar dotnet test desde la raíz de la solución y ejecutará todas las pruebas.
Me gustaría generar informes basados en https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-code-coverage?tabs=windows#integrate-with-net-test que ejecuto dotnet test --collect:"XPlat Code Coverage" que genera un archivo de cobertura.cobertura por proyecto de prueba.
Basado en https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-code-coverage?tabs=windows#generate-reports Sé que puedo instalar la herramienta dotnet-reportgenerator-globaltool y obtenga un informe HTML visual basado en cada archivo de cobertura.cobertura.
Pero quiero agregar una tubería de CI en la que quiero que la tubería falle cuando la cobertura de la línea esté por debajo del x %.
Dada la siguiente configuración de ejemplo de Gitlab CI
image: mcr.microsoft.com/dotnet/sdk:5.0 stages: - tests tests: stage: tests script: - dotnet test --collect:"XPlat Code Coverage" ¿Cómo puedo recopilar todos los archivos de coverage.cobertura.xml generados, leer la cobertura de la línea y dejar que la canalización falle si el valor es inferior, por ejemplo, al 80 %?
Ejemplo:
tests: stage: tests script: - dotnet test --collect:"XPlat Code Coverage" # for each coverage.cobertura file found in the test projects # parse the file # read the line coverage # fail if the value is less than 80 percent¡Sería bueno si no tuviera que reinventar la rueda si herramientas como xUnit ya brindan esa funcionalidad!
Editar:
Sé que también podría usar la palabra clave allow_failure para dejar esta etapa en estado de advertencia. Esto estaría bien para mí, solo quiero saber cómo leer la información requerida de los informes generados y validarlos para decidir si esa etapa debe pasar, fallar o ser inestable.
1 answers
Answer question0
Esto puede sonar como un enfoque realmente novato, pero aquí hay algo que funcionó para mí. Estoy usando Azure Devops y tuve varios proyectos similares, lo que resultó en múltiples archivos de cobertura.cobertura por proyecto de prueba.
Primero utilicé la tarea Generador de informes para fusionar todos los informes de cobertura en uno y almacenarlo en el directorio de trabajo. A continuación se muestra el yaml. Estoy generando ambos, HtmlFormat y el informe de Cobertura
- task: Palmmedia.reportgenerator.reportgenerator-build-release-task.reportgenerator@4 displayName: ReportGenerator inputs: reports: '$(Build.SourcesDirectory)/**/*cobertura.xml' targetdir: '$(System.DefaultWorkingDirectory)/CoverageResults' reporttypes: 'HtmlInline_AzurePipelines;Cobertura'El informe de cobertura resultante se ve así:
Después de esto, intenté leer este informe xml combinado usando la tarea PowerShell
- powershell: | [XML]$coverage = Get-Content $(System.DefaultWorkingDirectory)/CoverageResults/Cobertura.xml if($coverage.coverage.'line-rate' -ge .50){Write-Host "The value is greater than 50."}else{throw} displayName: 'PowerShell Script'En esta tarea, trato de leer el archivo de cobertura y luego accedo al atributo de tasa de línea. Si la tasa de línea del informe fusionado no es mayor o igual a 50, estoy arrojando un error. Con ErrorActionPreference establecido en Detener para mi tarea de PowerShell, la canalización se detiene si la cobertura de la línea no es la esperada. También puede incluir otras condiciones como la tasa de sucursal para una mayor precisión.
Supongo que hay mucho que mejorar en esto, pero esto fue solo una solución rápida que se me ocurrió. Por favor, siéntase libre de sugerir mejoras