Incorrect Code coverage reporting for C# Object Initializers
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- csharp
- Área
- testing-qa
Línea de trabajo
Comienza reproduciendo el patrón de inicializador de objetos y colecciones reportado y su equivalente con asignaciones explícitas usando vstest.console 17.14.0-release-25203-01 y 18.0.1-release-25520-05. Compara los informes de cobertura resultantes; se considera terminado cuando las instrucciones del inicializador aparecen como cubiertas al ejecutar completamente la ruta de código, o cuando se documentan la limitación y la solución alternativa.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
We are running into an issue where code coverage reports incorrect or partial coverage for certain C# object/collection initializer patterns, even though the code path is fully executed.
Specifically, the following initializer-style pattern is not fully recognized by the coverage tool:
var thing = new Example
{
name = "object one",
[1] = '1',
[2] = '4',
[3] = '9',
Size = Math.PI,
['C', 4] = "Middle C"
};
To investigate, I ran the impacted tests locally using two versions of vstest.console:
17.14.0-release-25203-01
18.0.1-release-25520-05
In both cases, the coverage results remained unchanged, which suggests this is not resolved by upgrading the test runner.
What we’ve observed is that rewriting the same logic using explicit assignments (instead of initializer-style patterns) results in correct coverage being reported. For example, the following pattern is correctly recognized by the coverage tool:
var thing = new Example();
thing.name = "object one";
thing[1] = '1';
thing[2] = '4';
thing[3] = '9';
thing.Size = Math.PI;
thing['C', 4] = "Middle C";
Based on this, it appears to be a limitation or bug in how the underlying coverage engine handles certain object/collection initializer patterns, rather than an issue with our pipeline or configuration.
If this is a known limitation, or if there is a recommended workaround or escalation path, guidance would be appreciated.
Thanks!
- Lenguaje dominante
- C#
- Estrellas
- 125
- Forks
- 17
- Merge medio
- 1 h 17 min
- PR fusionados (30 d)
- 2
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/codecoverage
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
microsoft/codecoverage#246 · 6 comentarios ·
-
Forward SIGTERM to child process Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
microsoft/codecoverage#237 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
microsoft/codecoverage#234 · 1 comentario · 2 reacciones ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
microsoft/codecoverage#233 · 2 reacciones ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
microsoft/codecoverage#232 · 6 comentarios ·
Todos los issues de microsoft/codecoverage
Issues similares
-
type/automation type/tech-debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
t/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
ci-failure-cause test-failure
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
area:auth FE mvp P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
klasolsson81/jobbliggaren#1788 ·