Guía del usuario

1. Introducción

Fucini Coverage Studio convierte los archivos de traza de cobertura que su build ya produce en cobertura de primera clase dentro del editor — en VS Code y en Visual Studio. Lee veinticinco formatos, los normaliza en un único modelo canónico Fucini, combina varias ejecuciones de forma determinista y lo muestra en el propio editor — márgenes, CodeLens, información al pasar el ratón y una vista Covered Files — de modo que no hay un visor aparte por el que abandonar su editor. Las dos ediciones comparten un lector: el mismo informe da las mismas cifras, dígito a dígito, en ambas. Esta guía está escrita desde VS Code; donde Visual Studio difiere, un recuadro In Visual Studio dice cómo.

Está diseñado pensando en flujos de trabajo de seguridad funcional: cobertura MC/DC, cobertura de regiones e instanciaciones de C++, una puntuación compuesta ponderada por seguridad y un veredicto COMPLIANT / NON-COMPLIANT configurable, alineado con los enfoques de IEC 61508, ISO 26262 y DO-178C.

Screenshot pending — add assets/img/marketplace-demo.gif (see SCREENSHOTS.md).

2. Instalación y requisitos

• VS Code ≥ 1.88 — la versión mínima que admite esta extensión — o Visual Studio 2022 o 2026, Community, Professional o Enterprise (vea el recuadro más abajo).
• Un archivo de traza de cobertura que su proyecto ya produce (vea §4).

Instale la extensión desde el Marketplace, o desde un archivo .vsix mediante Extensions → ⋯ → Install from VSIX…. La extensión se activa al iniciar y añade un icono Coverage a la barra de actividad.

3. Inicio rápido

1. Genere un archivo de traza de cobertura con su flujo de pruebas habitual.
2. Paleta de comandos (Ctrl+Shift+P) → Fucini Coverage: Load Coverage. Con watch.enabled activado (valor predeterminado), un archivo coincidente se carga automáticamente.
3. Abra un archivo fuente con cobertura: la barra de estado muestra su porcentaje, la vista Coverage se rellena, al pasar el cursor sobre una línea se ve su recuento de aciertos, y la ejecución aparece en el panel nativo Test Coverage. Las barras en las líneas sin cubrir, un mapa de calor de recuentos de aciertos y los recuentos ×N en línea están a un ajuste de distancia (editorGutter.mode, hitCounts.inline).

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

4. Generación de archivos de traza

Al cargar se detectan automáticamente cualquiera de los siguientes:

C / C++ — LLVM (llvm-cov)

clang --coverage -fprofile-instr-generate -fcoverage-mapping test.c -o test
LLVM_PROFILE_FILE=test.profraw ./test
llvm-profdata merge -sparse test.profraw -o test.profdata
llvm-cov export ./test -instr-profile=test.profdata --format=json > coverage.json

El JSON de llvm-cov es la entrada más completa: además de líneas, ramas y funciones, incluye regiones, MC/DC e instanciaciones de plantillas de C++.

C / C++ — GCC (gcov → lcov)

gcc --coverage calc.c calc_test.c -o test && ./test
lcov --capture --directory . --output-file lcov.info
# or gcovr --cobertura coverage.xml
# or skip the conversion entirely: gcovr --json coverage.json

JavaScript / TypeScript — Istanbul / nyc

nyc --reporter=json mocha        # emits coverage/coverage-final.json

Java — JaCoCo

mvn test        # emits target/site/jacoco/jacoco.xml

Ruby — SimpleCov

# .resultset.json (built-in) or coverage.json via the simplecov-json gem

Go

go test ./... -coverprofile=coverage.out    # read directly, no conversion

Python — coverage.py

coverage run --branch -m pytest && coverage json    # emits coverage.json

PHP — PHPUnit (Clover)

XDEBUG_MODE=coverage phpunit --coverage-clover clover.xml

.NET / C# — Coverlet (OpenCover)

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover

Un proyecto C++ nativo, medido desde Visual Studio

Screenshot pending — add assets/img/vs-native-run.gif (see SCREENSHOTS.md).

5. Carga y detección

De forma predeterminada, la extensión analiza desde la raíz del espacio de trabajo. Afine esto con dos ajustes:

{
  "fuciniCoverage.coverageFile.defaultLocation": "${workspaceFolder}/build",
  "fuciniCoverage.coverageFile.paths": [
    "coverage.json",
    "reports/*.info",
    "${env:CI_ARTIFACTS}/lcov.info",
    "https://ci.example.com/artifacts/latest/coverage.xml"
  ]
}

• Cada entrada de paths es relativa a defaultLocation (o a la raíz del espacio de trabajo si no se establece).
• Una entrada que contenga * se busca recursivamente; un nombre de archivo sin comodines solo coincide directamente en la carpeta base.
• Cuando paths está vacío, la extensión busca primero coverage.json y luego lcov.info, cargando el que encuentre primero.
• Pick Coverage File usa los archivos que elija en lugar de estas rutas —cada elección se añade al conjunto y todas se fusionan— hasta que los descargue o edite estos ajustes.
• Variables — todos los ajustes de ruta expanden ${workspaceFolder}, ${workspaceFolderBasename}, ${userHome}, ${env:NAME}, ${command:id} y ${config:section.key}. Una variable que la extensión no conoce se deja tal como está escrita, de modo que una errata aparece en el registro de detección como la ruta que se buscó en lugar de desaparecer. ${command:id} ejecuta antes ese comando — solo en un área de trabajo de confianza y durante cinco segundos como mucho —, de modo que ${command:cmake.buildDirectory} sigue el kit de CMake seleccionado.
• Entradas URL — una entrada http(s):// se descarga al almacenamiento de la extensión en cada carga y se carga desde allí; la vista Coverage nombra la URL. Cada descarga es condicional (ETag / Last-Modified), así que un artefacto sin cambios no descarga nada, y cuando una descarga falla se carga en su lugar la última copia descargada, con el motivo en la salida. remote.headers añade cabeceras Name: value con las variables expandidas, remote.refreshMinutes vuelve a descargar con un temporizador, y un fragmento #lcov.info nombra el formato cuando la propia URL no termina en un nombre de archivo.
• Globs de exclusión — fuciniCoverage.ignore descarta archivos enteros (de proveedores, generados, de terceros) de la ejecución mientras se carga, de modo que cada vista, control y exportación cuenta sin ellos; el resultado de la carga dice cuántos se dejaron fuera y la salida los nombra. Los patrones se comparan con la ruta relativa al espacio de trabajo y con la absoluta, y un patrón sin / coincide con un nombre de carpeta o de archivo a cualquier profundidad, como en .gitignore.
• Espacios de trabajo multirraíz — cada carpeta se detecta por su cuenta: defaultLocation, paths, pathRemap, ignore, watch.* y remote.* se leen por carpeta, de modo que se aplica el .vscode/settings.json propio de la carpeta o su entrada en el .code-workspace, y ${workspaceFolder} en una entrada significa la carpeta de esa entrada. Los archivos de traza de todas las carpetas se fusionan en una sola ejecución, la vista Coverage agrupa los archivos por carpeta, y una carpeta añadida al espacio de trabajo o quitada de él recarga la cobertura por sí sola.
• Recarga tras una tarea — watch.reloadAfterTasks nombra tareas (un label de tasks.json, o source: name tal como lo muestra la lista Run Task) cuyo final recarga la cobertura, esté o no activado watch.enabled — para compilaciones que el observador no puede seguir. Una entrada absoluta de paths fuera del espacio de trabajo también se sondea, de modo que un archivo que aparece allí se carga.
• Progreso que se puede cancelar — una carga de diez o más archivos de traza, o de 8 MB o más, se ejecuta bajo una notificación de progreso con un botón Cancelar que nombra el archivo que se está leyendo y la fase; una más pequeña solo hace girar la barra de estado. Cancelar deja cargada la ejecución anterior y lo dice.

Desde 1.2026.6 una entrada absoluta también puede llevar un comodín: ${workspaceFolder}/build/coverage-merged/*.lcov.info carga todos los archivos así de esa carpeta, y ** representa cualquier profundidad. Las carpetas anteriores al primer comodín son donde busca, y se vigilan, de modo que un informe que una compilación escriba allí se carga por sí solo. La edición para Visual Studio lee una entrada así de la misma manera, y desde 1.2026.5 un comodín relativo también se busca allí a cualquier profundidad, como siempre se ha hecho aquí.

Si no hay ningún paths configurado, se carga el primero de los nombres de informe habituales que se encuentre bajo la carpeta base. Primero los cuatro que siempre se han buscado —coverage.json, lcov.info, coverage.out, clover.xml—; después, desde la versión 0.2026.83, jacoco.xml, coverage.xml, cobertura.xml, coverage.cobertura.xml, coverage.opencover.xml y coverage-final.json, y a continuación los lugares donde escriben las configuraciones predeterminadas: coverage/ (nyc, Jest, vitest, PHPUnit, SimpleCov), target/site/jacoco/jacoco.xml (Maven), build/reports/jacoco/test/jacocoTestReport.xml (Gradle) y TestResults/*/coverage.cobertura.xml (dotnet test). Así, un proyecto Java o .NET muestra su cobertura la primera vez que se abre, como siempre lo ha hecho un proyecto lcov.

Desde 1.2026.3 una solución .NET necesita aún menos: la carpeta TestResults/<run>/ de cada proyecto de pruebas está entre los lugares conocidos, no solo la de la propia carpeta del espacio de trabajo, y el <user>_<machine>_<date>.cobertura.xml del recopilador de Microsoft se encuentra junto al coverage.cobertura.xml de Coverlet — así que una solución cuyas pruebas se ejecutaron en el Test Explorer de Visual Studio muestra su cobertura al abrirse por primera vez, cada carpeta de ejecución se carga, y la fusión conserva para cada archivo lo que dice la ejecución más reciente. Y fuciniCoverage.ignore.generated, activado por defecto, deja los archivos de diseñador y los generados — *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, los usings globales, Migrations/ y obj/ — fuera de cada total, página y exportación antes de que se aplique ignore, de modo que una tabla generada que nadie prueba no le cuesta a la solución su puerta.

Un artefacto de CI tras un token, comprobado de nuevo cada cuarto de hora — el token se queda en el entorno, nunca en settings.json:

{
  "fuciniCoverage.coverageFile.paths": [
    "https://ci.example.com/api/builds/latest/artifacts/coverage#lcov.info"
  ],
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:CI_TOKEN}"],
  "fuciniCoverage.remote.refreshMinutes": 15
}

Screenshot pending — add assets/img/remote-tracefile.png (see SCREENSHOTS.md).

Una recarga es silenciosa a propósito: un diálogo tras cada compilación es una pregunta con una sola respuesta. Lo que no es silencioso es el icono Coverage: mientras la vista no esté delante de usted, lleva el número de tracefiles vueltos a leer, y su información sobre herramientas los nombra. Abra la vista y la cuenta desaparece.

Screenshot pending — add assets/img/coverage-badge.gif (see SCREENSHOTS.md).

Archivos que nunca deben contar, diga lo que diga de ellos el archivo de traza:

{
  "fuciniCoverage.ignore": ["vendor/**", "**/*.generated.ts", "build/**"]
}

Una recarga cuando termina la tarea de pruebas, para una compilación que el observador de archivos no puede seguir — una ejecución que reemplaza un árbol de salida con enlaces simbólicos, un informe en un recurso compartido de red, un paso de cobertura que posprocesa su archivo:

{
  "fuciniCoverage.watch.reloadAfterTasks": ["npm: test", "coverage-report"]
}

6. Fusión de ejecuciones

Cada entrada paths existente se carga y se fusiona en una sola ejecución. La fusión es determinista — el resultado no depende del orden de carga — y un archivo medido por más de un tracefile toma sus números del que tenga la mtime más reciente en disco: la repetición propia de un módulo reemplaza lo que una ejecución más amplia y antigua decía de él, en lugar de sumarse. La vista de Cobertura muestra lo que eso hizo: cada fila de archivo nombra el tracefile del que proceden sus números, la insignia lleva contorno donde esos números anularon un informe más antiguo, cada fila de tracefile sobre el árbol cuenta cuántos de sus archivos fueron anulados o anularon otros, y hacer clic en una fila de tracefile resalta sus archivos en el árbol hasta volver a hacer clic (coverageView.mergedMarks desactiva el contorno y el resaltado).

Screenshot pending — add assets/img/four-reports-one-file.svg (see SCREENSHOTS.md).

Una ejecución fusionada puede contener más que las seis métricas clásicas, cada una procedente del informe que la mide: llamadas a funciones, código objeto y una puntuación de mutación junto a líneas, funciones, regiones, ramas, MC/DC e instanciaciones. La vista Coverage muestra una columna por cada métrica que la ejecución contiene —y ninguna para las que no contiene— ordenadas por el peso de cada métrica en su puntuación, la más pesada primero y con cualquier anchura: lo que no cabe se desplaza lateralmente en lugar de desaparecer. Arrástrela al panel inferior y se convierte en una tabla. Las tarjetas de la barra de estado, el informe HTML y las exportaciones CSV y Markdown siguen la misma regla: lo que un informe contiene se muestra, y lo que no contiene se omite en lugar de imprimirse como un cero.

Screenshot pending — add assets/img/coverage-view-editor.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/coverage-view-columns.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/workspace-overview.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-workspace-overview.gif (see SCREENSHOTS.md).

De qué informe procede un archivo

Cuando varios informes cargados miden el mismo archivo, el más reciente se lo queda por completo — lo correcto cuando la nueva ejecución de un módulo sustituye lo que decía una ejecución anterior y más amplia. Es incorrecto cuando los informes miden el mismo código a propósito: entonces el editor salta de uno a otro con cada compilación, y cada uno cuenta solo parte de la historia. coverageFile.sources dice qué hacer en su lugar, por archivo. Tres situaciones lo requieren:

• Un informe es el mejor. El coverage.json de llvm-cov incluye MC/DC; un gcov.info de GCC de la misma compilación, solo líneas y ramas: elija coverage.json y conserve el otro para los pocos archivos que solo compila GCC.
• Varias suites de pruebas de una compilación. Las pruebas unitarias, las de integración y las de hardware-in-the-loop escriben cada una un informe; cada uno por sí solo deja fuera líneas que los otros ejecutaron. Combinar, union: una línea está cubierta donde cualquier informe la ejecutó, y los recuentos se suman.
• Una base de código, dos compiladores. Las mismas fuentes compiladas con clang y con GCC toman caminos distintos por el código específico de cada toolchain — un intrínseco aquí, una alternativa portable allá — y cada informe dice que la otra mitad nunca se ejecutó. Combinar, agree: una línea está cubierta solo donde todos los informes que la miden la ejecutaron, y las líneas en las que discrepan se marcan en verde azulado. Esa es la pregunta que plantea una comprobación cruzada entre compiladores: ¿qué ejercitó realmente cada compilación que entrego?

Rara vez escribirá las reglas a mano. Haga clic con el botón derecho en un archivo de la vista Cobertura y elija Choose Coverage Source... (o ejecute Choose Coverage Source for This File... sobre el archivo abierto): se listan todos los informes que miden el archivo, cada uno con sus propias líneas, ramas y MC/DC, y después Combine them — agree y Combine them — union; elija uno e indique si vale para el archivo, su carpeta o un patrón. Clear Coverage Source for This File... vuelve a quitar la regla. En los ajustes, cada regla es un glob sobre los archivos, un glob sobre el informe (un patrón sin / coincide con el nombre de archivo del informe, {a,b} nombra varios) y, para combinar, "combine": "agree" o "union". Decide la primera regla cuyos archivos coinciden y cuyo informe mide el archivo; a un archivo que solo mide un informe nunca se le quita ese informe. Las ramas, el MC/DC y las regiones de un archivo combinado proceden del informe más rico en ellos. coverageFile.mergeStrategy: "order" resuelve los archivos de los que no habla ninguna regla por el orden de coverageFile.paths en lugar de por las horas.

{
  "fuciniCoverage.coverageFile.paths": ["clang.json", "gcc/bits.gcov.json.gz"],
  "fuciniCoverage.coverageFile.sources": [
    { "files": "src/**", "report": "{clang.json,bits.gcov.json.gz}", "combine": "agree" }
  ]
}

Lo que verá: la fila del archivo en la vista Cobertura nombra el informe del que proceden sus números o, si está combinado, todos los informes y el modo, con ≠ n para las líneas en disputa. El margen y Annotated Source marcan esas líneas en verde azulado y dicen qué informe las ejecutó y cuántas veces. La tarjeta emergente de la barra de estado nombra la fuente del archivo abierto y, para toda la ejecución, las reglas vigentes y cómo se decidieron los demás archivos. El samples/c-cross-check de la demo es el caso de dos compiladores, listo para abrir. Visual Studio también hace todo esto: Choose Coverage Source... en una fila de la vista Cobertura, y Choose y Clear Coverage Source for This File... en Tools > Coverage Studio.

Elegir y combinar fuentes forma parte de los planes de pago. En Community el informe más reciente gana cada archivo, como sin ninguna regla, y una regla en los ajustes se indica como no utilizada en lugar de ignorarse en silencio.

7. Remapeo de rutas

La integración continua a menudo registra rutas absolutas de la máquina de compilación que no existen en su estación de trabajo. Reescríbalas con reglas ordenadas:

{
  "fuciniCoverage.pathRemap": [
    { "from": "/builds/ci/project", "to": "${workspaceFolder}" },
    { "from": "\\\\", "to": "/" }
  ]
}

Las reglas se aplican en orden; la primera coincidencia gana por prefijo. Úselo para salvar diferencias de separadores Windows/Unix o para mapear una ruta de contenedor a su copia de trabajo.

Rara vez tendrá que escribir la regla usted mismo. El «se cargó pero no se ilumina nada» más habitual es un archivo de traza cuyas rutas vienen de un contenedor o de un checkout de CI (/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c) mientras que el espacio de trabajo tiene src/a.c. Cuando una carga deja archivos sin coincidencia, la extensión busca los nombres de archivo en el espacio de trabajo, infiere la regla de prefijo que explica el mayor número de ellos, la registra como [FUCINI_REMAP_002], y el resultado de la carga ofrece Apply Suggested Remap — un clic añade la regla a fuciniCoverage.pathRemap y recarga. Suggest Path Remap Rule ejecuta el mismo análisis bajo demanda desde la paleta. No se escribe nada sin el clic.

Un to puede usar ${workspaceRoot}, que representa la carpeta del espacio de trabajo en la que está el archivo de traza; en un espacio de trabajo multirraíz prueba primero esa carpeta y luego todas las demás que resulten tener el archivo. Las propias reglas se leen por carpeta, de modo que cada raíz de un espacio de trabajo multirraíz puede tener las suyas.

8. Cobertura en el editor

• Márgenes y regla — de forma predeterminada el propio margen del editor muestra solo hallazgos: barras MC/DC, triángulos de desde-la-última-ejecución, puntos de líneas editadas. editorGutter.mode añade barras solo en las líneas sin cubrir o un mapa de calor de recuentos de aciertos (más abajo); la vista codificada por colores de un archivo entero es Annotated Source.
• CodeLens de función — % de cobertura sobre cada función; haga clic para saltar a su primera línea no cubierta. Se activa o desactiva con codeLens.enabled.
• Información al pasar el cursor sobre ramas y MC/DC — pase el cursor sobre una línea de decisión para ver los recuentos de tomado/no tomado por rama y una tabla de vectores por condición. Active una barra de margen coloreada con mcdcGutter.enabled.
• Avisos de código muerto — las funciones con líneas medibles y cobertura nula se marcan en el panel Problems (deadCode.enabled).
• Next / Previous Uncovered — salte entre huecos.
• Barra de estado — un elemento $(dashboard) NN% para toda la ejecución y un elemento por archivo, ambos coloreados según la puntuación compuesta; pase el cursor para ver una tabla completa de métricas.
• Insignias del Explorador — insignias de cobertura por archivo y por carpeta, con el desglose por métrica al pasar el ratón. Desactivadas de forma predeterminada: actívelas con explorerBadges.enabled.
• Desde la última ejecución — un triángulo rojo en cada línea ejecutada en la ejecución anterior y no en esta, uno verde para el caso inverso, con la regla de vista general y los recuentos al pasar el ratón.
• Búferes editados — cada marca, descripción emergente y CodeLens se mueve con el texto al editar, y se retira de una línea reescrita, donde un punto gris dice por qué.
• Recuentos de aciertos en línea — hitCounts.inline escribe ×12 tras cada línea en la que empieza una sentencia, ×0 incluido: el número que siempre ha estado al pasar el cursor, sin pasar el cursor. Toggle Inline Hit Counts lo alterna; el menú de la barra de estado lo ofrece como Mostrar u Ocultar, según corresponda.
• Entradas por línea en Problems — problems.perLine pone un diagnóstico de tipo Information, con un subrayado ondulado en el editor, en cada bloque contiguo de líneas que nunca se ejecutaron en un documento abierto (una función muerta de cuarenta líneas es una entrada, no cuarenta) y, como uncoveredAndPartial, en cada línea con una rama nunca tomada. Las entradas siguen a sus líneas mientras edita y desaparecen al cerrar el documento; la entrada por archivo que hay tras problems.enabled no cambia.
• Tinte de línea — lineHighlight pone un tinte translúcido detrás de las líneas mismas, para lo que marca el margen (uncovered, o heatmap también para las líneas ejecutadas). Una opción propia, para que el margen pueda quedar limpio mientras se tiñen los huecos, o al revés.
• Regla de vista general — overviewRuler decide la franja de la barra de desplazamiento con independencia del margen: follow (con las barras, como antes), uncovered (siempre, de modo que el margen puede estar desactivado mientras la barra de desplazamiento sigue mapeando los huecos) u off.
• Qué archivo de traza cubrió una línea — con varios informes combinados, la información al pasar el cursor termina con Cubierto por: y cada informe que cubrió esa línea, incluido el nombre de suite del TN: de lcov; un clic en una fila de archivo de traza en la vista Coverage ilumina las líneas que aportó en cada editor abierto.

Screenshot pending — add assets/img/codelens-hover.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/codelens-crap.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/jump-between-gaps.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/explorer-badges.png (see SCREENSHOTS.md).

Modos de margen del editor

editorGutter.mode decide qué muestra el propio margen del editor sobre la cobertura, además de los hallazgos que muestra siempre. off (el valor predeterminado) es solo esos. uncovered pone una barra en cada línea que nunca se ejecutó y una ámbar en cada línea con una rama nunca tomada, y nada en las líneas cubiertas, de modo que una pared verde no oculte las tres rojas. coverage añade una barra verde en cada línea cubierta, de modo que todo el archivo se lee en rojo, ámbar y verde con los colores de la escala de colores. heatmap añade en su lugar un tono cálido en cada línea ejecutada, más intenso cuantas más veces se ejecutó — muestra cuántas veces se ejecutó una línea, no si está cubierta, así que un archivo al 100% aparece ahí de amarillo a marrón, nunca verde. Choose Editor Gutter Mode... elige uno desde la paleta o el menú de la barra de estado; el botón de modo a la derecha de la barra de estado, o Alt+G, pasa al siguiente con una sola pulsación (statusBar.showModeToggle oculta el botón). Ambos escriben el ajuste. El ejemplo activa a la vez las barras de líneas sin cubrir y los recuentos en línea:

{
  "fuciniCoverage.editorGutter.mode": "uncovered",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

El mapa de calor es relativo al archivo. El tono de una línea compara su recuento con el de la línea más caliente del mismo archivo, en una escala logarítmica y en cinco pasos; así, el cuerpo de un bucle que se ejecutó mil veces y una función que se ejecutó dos veces son ambos visibles, en lugar de que uno eclipse al otro, y un archivo en el que todo se ejecutó exactamente una vez queda uniformemente cálido en lugar de uniformemente pálido. En un tema oscuro la gama va del oliva apagado al naranja vivo, y en un tema claro del amarillo pálido al marrón: en ambos casos más color significa más ejecuciones, y el rojo queda reservado para las líneas que nunca se ejecutaron. lineHighlight: "heatmap" coloca los mismos tonos detrás del código como un fondo, y hitCounts.inline escribe el recuento exacto después de la línea.

{
  "fuciniCoverage.editorGutter.mode": "heatmap",
  "fuciniCoverage.lineHighlight": "heatmap",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/heatmap-dark.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap-light.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap.gif (see SCREENSHOTS.md).

Los colores los elige usted. colorScale.lowColor, midColor y highColor dan el rojo, el ámbar y el verde del margen, de los tintes de línea y de cada porcentaje; heatmap.colors y heatmap.colorsDark contienen los cinco tonos del mapa de calor para un tema claro y uno oscuro, desde la línea que menos se ejecutó hasta la que más. La página de ajustes muestra el resultado antes de guardar nada: bajo Colour scale, una vista previa permanece a la vista mientras las filas se desplazan — el degradado con sus dos puntos de pivote, algunos porcentajes en sus colores, y un pequeño editor claro y otro oscuro pintados en el modo coverage y en el mapa de calor — y se vuelve a pintar en cuanto se elige un color.

{
  "fuciniCoverage.heatmap.colors": ["#e3f2fd", "#90caf9", "#42a5f5", "#1e88e5", "#0d47a1"]
}

La parte de una línea que nunca se ejecutó

Una línea está cubierta o no lo está, y la verdad suele quedar en medio: return x > hi ? hi : x; se ejecutó, pero su rama hi nunca. Con lineHighlight activado, la parte nunca ejecutada de una línea ejecutada se tiñe en el editor, para todos los formatos que incluyen rangos de columnas (llvm-cov, Istanbul, Go, dotnet-coverage): los mismos tramos que marca el código fuente anotado. Solo en las líneas que se ejecutaron: una línea que nunca se ejecutó ya está marcada entera. Una plantilla de C++ cuenta como ejecutada allí donde cualquier instanciación la ejecutó; lo que hizo cada instanciación es lo que informa la métrica de instanciaciones.

Screenshot pending — add assets/img/partial-line.png (see SCREENSHOTS.md).

Qué pruebas ejecutaron esta línea

Algunos informes no solo dicen que una línea se ejecutó, sino qué pruebas la ejecutaron: coverage.py escrito con coverage json --show-contexts y dynamic_context = test_function en .coveragerc, OpenCover recopilado con -coverbytest, y un archivo de traza lcov escrito con una sección por prueba (TN:), cuyas secciones se suman en un solo registro con una prueba por línea. Pase el cursor sobre el inicio de una línea, donde está el contador de ejecuciones, y se nombran las pruebas: abreviadas a clase y método, las cinco primeras por su nombre y el resto como una cifra; el CodeLens de la función dice cuántas pruebas la ejecutaron. Show Tests That Ran This Line — la Command Palette, el menú contextual del editor, en Visual Studio Tools → Coverage Studio o Ctrl+Shift+U, T — las enumera, las más activas primero, y abre la que elija donde está escrita en el espacio de trabajo. Una ejecución de dotnet test no sabe decir qué prueba ejecutó qué; active testRun.perTest y Run Tests with Coverage enumera las clases de prueba y las ejecuta una a una, cada informe etiquetado con su clase, de modo que la información al pasar el cursor, la lente y el comando responden también para .NET. Se conserva por archivo, de modo que sobrevive a una fusión con un informe que no sabe nada de pruebas.

{
  "fuciniCoverage.testRun.perTest": true
}

# .coveragerc
[run]
dynamic_context = test_function

coverage run -m pytest && coverage json --show-contexts

Screenshot pending — add assets/img/tests-per-line.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/tests-for-line.gif (see SCREENSHOTS.md).

Aprobado o fallido, en las marcas

Una línea cubierta se ve igual tanto si su prueba pasó como si no. Donde el informe dice qué pruebas ejecutaron una línea y el archivo de resultados del ejecutor dice cómo terminaron, una línea que ejecutó una prueba fallida recibe una barra roja en su inicio y una franja en la regla de vista general; la información al pasar el cursor nombra las pruebas fallidas, y Show Tests That Ran This Line escribe fallida junto a cada una. Cuando una prueba está en rojo, el sitio donde mirar es el código por el que pasó. Los resultados se leen en cada carga de la carpeta de cada informe — cualquier .trx, y los nombres que usan las herramientas que escriben JUnit (TEST-*.xml, junit*.xml, test-results*.xml) — y de testResults.paths, como rutas o globs relativos a la carpeta. Run Tests with Coverage pide a dotnet test un test-results.trx junto al informe, de modo que con testRun.perTest activado no hay que configurar nada. testResults.enabled desactiva esa lectura.

{
  "fuciniCoverage.testResults.paths": ["build/test-results/**/*.xml", "reports/junit.xml"]
  }

Screenshot pending — add assets/img/pass-fail.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-pass-fail.gif (see SCREENSHOTS.md).

Las pruebas a las que afecta un cambio

Una ejecución completa responde despacio a lo que Run Tests Affected by My Changes… responde al instante: de todas las pruebas, ¿cuáles pasaron por el código que acabo de editar? Se pide a git el diff del árbol de trabajo respecto a testImpact.baseRef — HEAD por defecto, que es lo que aún no está en un commit; origin/main para todo lo que cambia la rama — y se enumeran las pruebas que ejecutaron una línea modificada, primero la que ejecutó la mayor parte del cambio. Elegir una prueba la abre. Donde los informes proceden de una ejecución por prueba (testRun.perTest), la primera entrada ejecuta solo esas pruebas, cada clase en su propio informe, de modo que el informe de todas las demás clases sigue valiendo y los totales siguen siendo los de toda la suite. Una prueba que solo ejecutó líneas situadas debajo de una inserción o una eliminación también aparece: de lo contrario, su informe nombraría las líneas equivocadas.

Screenshot pending — add assets/img/test-impact.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-test-impact.gif (see SCREENSHOTS.md).

El menor número de pruebas que siguen ejecutando todas las líneas

Show Minimal Test Set… responde a dos preguntas a partir de las mismas líneas por prueba: qué pocas pruebas seguirían ejecutando todas las líneas que ejecuta la suite — para la ejecución rápida antes de un commit — y qué pruebas no ejecutan ninguna línea que otra no ejecute ya. Las pruebas elegidas van primero, cada una con las líneas que añade y las líneas que solo ella ejecuta; después el resto, cada una marcada como que no añade nada. La elección es la voraz — la prueba que más líneas ejecuta, luego la que más añade a esas —, así que se acerca al conjunto más pequeño y es la misma cada vez. Redundante por líneas no es redundante por lo que una prueba comprueba: una prueba que no añade ninguna línea puede ser aun así la única que comprueba un valor en esas líneas. La lista dice dónde mirar cuando se poda una suite, nunca qué borrar.

Screenshot pending — add assets/img/minimal-test-set.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-minimal-test-set.png (see SCREENSHOTS.md).

Ejecutar esta prueba, con cobertura

Ponga el cursor en una prueba y ejecute Run This Test with Coverage — la Command Palette, el menú contextual del editor, en Visual Studio Tools → Coverage Studio o Ctrl+Shift+U, R — y solo esa prueba se ejecuta con la cobertura activada: el método de prueba en el que está el cursor, o la clase de prueba o el bloque describe cuando está entre métodos, o el archivo cuando está por encima de toda clase. Lo que hay bajo el cursor se lee del texto, así que funciona para C#, VB y F# ([Fact], [Test], [TestMethod] y similares), JavaScript y TypeScript (it, test, describe) y Python (def test_…), sea cual sea el servicio de lenguaje instalado. La receta de la carpeta se acota a ella — dotnet test --filter "FullyQualifiedName~…", jest o vitest <file> -t "…", un id de nodo de pytest — y lo que escribió se carga como cualquier ejecución; un ejecutor que no se puede acotar lo dice, y Run Tests with Coverage las ejecuta todas.

Screenshot pending — add assets/img/run-this-test.gif (see SCREENSHOTS.md).

Go y Rust. En un archivo Go, el func TestXxx (o Fuzz…, Example…) en el que está el cursor se ejecuta solo, en su propio paquete y por su nombre exacto — go test ./pkg/calc -run "^TestTotal$" — y fuera de una prueba se ejecuta el paquete del archivo. En un archivo Rust, la función #[test] se ejecuta por su ruta en el crate con --exact; con el cursor en un mod y en ninguna prueba, se ejecutan las pruebas de ese módulo; una prueba de integración bajo tests/ se ejecuta en su propio binario (--test api). A un ejecutor solo se le entregan archivos de su propio lenguaje: un archivo TypeScript en una carpeta Go recibe una frase, no una ejecución de nada.

Cobertura tras cada guardado

Con testRun.onSave activado, guardar un archivo fuente ejecuta las pruebas que lo cubren, con cobertura, un momento después de guardar, y el margen lo sigue. Para una solución .NET, el proyecto del archivo guardado se encuentra a través del grafo de .csproj y solo se ejecutan los proyectos de pruebas que lo referencian — directamente, o a través de otros proyectos —, un dotnet test <project> cada uno; cualquier otro ejecutor ejecuta su receta completa; un archivo que no pertenece a ningún proyecto y que ningún informe mide no ejecuta nada. Varios guardados seguidos son una sola ejecución, y una ejecución ya en marcha no se interrumpe. El resto es como lo hace Run Tests with Coverage: el terminal, el panel Output, el informe cargado. Desactivado por defecto — es un hábito que se elige, no un valor predeterminado que se descubre.

{
  "fuciniCoverage.testRun.onSave": true
}

Screenshot pending — add assets/img/coverage-on-save.gif (see SCREENSHOTS.md).

La propia aplicación, con cobertura

Una ejecución de pruebas dice lo que alcanzan las pruebas. Lo que alcanza una persona — al recorrer las pantallas antes de una versión, al repetir los pasos de un cliente — también es cobertura, y Run App with Coverage… la recoge. La aplicación .NET de la carpeta — un Exe, un WinExe, un proyecto web o worker, nunca un proyecto de pruebas; una elección cuando hay varias — se inicia bajo dotnet-coverage de Microsoft en una consola propia, para que se pueda escribir en una aplicación de consola, y se ejecuta hasta que usted la cierra. Lo que recorrió se carga entonces como cualquier ejecución, y en una sesión de cobertura se suma a lo que ejecutaron las pruebas. Cómo terminó la aplicación no cuenta en contra de la ejecución. La herramienta hay que instalarla una vez: dotnet tool install --global dotnet-coverage.

Screenshot pending — add assets/img/run-app.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-run-app.gif (see SCREENSHOTS.md).

Los mutantes, y dónde están

Una herramienta de mutación —PIT para Java, Stryker para JavaScript, C# y Scala, Mull para C y C++— modifica su código en pequeños detalles y ejecuta las pruebas contra cada cambio. Un cambio que ninguna prueba advierte es un mutante superviviente: el código se ejecutó y nada comprobó lo que hacía. La puntuación de mutación dice cuántos fueron detectados; desde la versión 0.2026.83, el editor dice dónde están los demás. Una línea que tiene uno lleva una nota detrás (⚑ 2 mutants survived), el texto modificado aparece subrayado cuando el informe indica de qué texto se trataba (Stryker y Mull lo hacen), la regla de vista general muestra una franja, y al pasar el cursor se ve qué se cambió, cuántas pruebas lo ejecutaron y, para los mutantes detectados, qué prueba los detectó.

Screenshot pending — add assets/img/mutant-hover.png (see SCREENSHOTS.md).

Sobrevivió significa que hubo pruebas que ejecutaron el código modificado y todas pasaron. Sin probar (el no coverage del informe) significa que ninguna prueba ejecuta ese código, de modo que nada habría podido advertirlo. Los mutantes detectados se cuentan al pasar el cursor y nunca se marcan, y los mutantes que nunca fueron una prueba justa —uno que no compilaría— quedan fuera de la puntuación. El código fuente anotado tiene una fila debajo de cada una de esas líneas y un botón Next Mutant (U), y los informes HTML tienen una sección Surviving Mutants que enlaza con la línea. No hay que activar nada, y un proyecto sin informe de mutación no ve nada de ello.

Screenshot pending — add assets/img/mutants.gif (see SCREENSHOTS.md).

¿Lo notaría una prueba? Una ejecución de mutación en el cursor

La ejecución de mutación de un proyecto lleva una hora; la de una función, un minuto. Run Mutation Tests Here ejecuta ese minuto: la función en la que está el cursor — o las líneas seleccionadas, o el archivo — es lo que se le indica mutar al ejecutor de mutación de la carpeta, y su informe se carga junto a la cobertura en pantalla, donde se marcan los mutantes supervivientes. Para C# es Stryker.NET (dotnet tool install --global dotnet-stryker), al que se le indican el intervalo de caracteres y el proyecto de pruebas que referencia el proyecto del archivo; para JavaScript y TypeScript, StrykerJS, al que se le indican las líneas; para Java, PIT con Maven, al que se le indica la clase. Cómo terminó el ejecutor no cuenta en contra de la ejecución: una puntuación por debajo de su umbral es un código de salida, y sigue siendo un informe. Un ejecutor que no escribió nada se señala, junto con lo que necesita tener instalado.

Screenshot pending — add assets/img/mutation-here.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mutation-here.gif (see SCREENSHOTS.md).

La propia vista Test Coverage de VS Code

Con testCoverage.publish activado (el valor predeterminado), cada ejecución cargada va también a la vista Test Coverage nativa del editor — el panel de cobertura del Test Explorer, los porcentajes por archivo que pone en el Explorer y el propio conmutador Show Inline Coverage del editor — como líneas, ramas y funciones, con los detalles cargados bajo demanda, vengan del archivo de traza que vengan y sin ningún adaptador de pruebas de por medio. Show in Test Coverage View publica la ejecución activa y abre el panel diga lo que diga el ajuste; el menú de la barra de estado lo ofrece tras quickActions.showTestCoverage. Desactivado, no aparece ninguna entrada Fucini Coverage en el Test Explorer. Cuando un archivo de traza nombra sus pruebas (las secciones TN: de lcov), cada prueba aparece bajo Fucini Coverage en el Test Explorer y la vista puede filtrar la cobertura de un archivo por prueba.

Screenshot pending — add assets/img/test-coverage-view.png (see SCREENSHOTS.md).

Líneas sin cubrir en el panel Problems

Desactivado de forma predeterminada porque es ruidoso por naturaleza, y solo para los documentos abiertos — una ejecución de dos mil archivos no puede inundar el panel. Independiente de problems.enabled, que se limita a una entrada por archivo:

{
  "fuciniCoverage.problems.perLine": "uncoveredAndPartial"
}

Screenshot pending — add assets/img/problems-panel.png (see SCREENSHOTS.md).

9. Cobertura de diferencias

Restrinja las decoraciones a las líneas modificadas respecto a una referencia base de git — ideal para revisar exactamente qué cubrió o no una PR:

{
  "fuciniCoverage.gitDiff.enabled": true,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
}

Screenshot pending — add assets/img/diff-coverage.png (see SCREENSHOTS.md).

Una puerta para el código nuevo

threshold.newCode es una puerta propia, junto a las que se aplican a toda la ejecución: de las líneas modificadas respecto a gitDiff.baseRef que se pueden medir, el porcentaje mínimo que debe haberse ejecutado. Un proyecto al 62 % en total puede exigir aun así que lo que se escribe hoy esté probado. Se calcula en cada carga sobre toda la ejecución, que sigue en pantalla — gitDiff.enabled es otra cosa: las líneas modificadas en lugar de la ejecución. Check Coverage Thresholds y las entradas de cumplimiento de Problems la dan por fallida en una frase propia: New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran). Un cambio sin ninguna línea que se pueda medir — comentarios, un README — no hace fallar nada.

{
  "fuciniCoverage.threshold.newCode": 80,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
  }

Screenshot pending — add assets/img/new-code-gate.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-new-code-gate.png (see SCREENSHOTS.md).

Código nuevo por etiqueta, por autor, por fecha

El código nuevo son, por defecto, las líneas que el árbol de trabajo cambia respecto a gitDiff.baseRef — una rama, un commit o una etiqueta: "v1.4.0" es todo lo posterior a esa versión. Dos ajustes preguntan lo que una referencia de git no puede. gitDiff.author toma parte del nombre de un autor, y el código nuevo son entonces las líneas que git atribuye a ese autor; gitDiff.since toma un día, y son las líneas modificadas por última vez ese día o después, sea cual sea la rama por la que llegaron; los dos juntos, las líneas de ese autor desde ese día. Se obtienen de git blame, archivo por archivo — algo que una ejecución grande notará en cada carga — y ocupan el lugar del diff para la cobertura de diferencias y para la puerta anterior. Una línea que aún no está en un commit cuenta en ambos casos.

{
  "fuciniCoverage.gitDiff.author": "Ada",
  "fuciniCoverage.gitDiff.since": "2026-09-01"
  }

Screenshot pending — add assets/img/new-code-author.png (see SCREENSHOTS.md).

Cambios indirectos: lo que se movió aunque nadie lo tocó

Un diff dice qué líneas cambiaron; dos ejecuciones dicen qué líneas dejaron de ejecutarse o empezaron a hacerlo. Las líneas que merecen un vistazo son aquellas en las que ambos discrepan: código que nadie editó y que ya no se ejecuta, porque se borró una prueba, porque una rama previa ahora retorna antes, porque cambió un fixture. Una revisión del diff no puede verlas — quedan fuera de él por definición. Show Indirect Coverage Changes… las enumera por archivo, primero el archivo que más perdió, y abre el que usted elija en su primera línea de ese tipo. La ejecución se compara con la línea base de CI donde baseline.report nombra una — que es por la que se juzga una pull request — y, si no, con la ejecución anterior; las líneas que el árbol de trabajo cambia respecto a gitDiff.baseRef, y todo lo que queda por debajo de un punto donde ese cambio desplaza las líneas del archivo, se dejan fuera.

Screenshot pending — add assets/img/indirect-changes.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-indirect-changes.png (see SCREENSHOTS.md).

10. La puntuación compuesta

En lugar de informar seis números, la extensión los combina en una única media armónica ponderada (WHM). Para métricas con porcentajes pᵢ y pesos wᵢ:

WHM = ( Σ wᵢ ) / ( Σ wᵢ / pᵢ )

Una media armónica está dominada por su término más pequeño, por lo que una métrica débil no puede quedar enmascarada por una perfecta — exactamente la propiedad que se busca en una puerta de seguridad. Pesos predeterminados:

Ponga cualquier peso en 0 para excluir esa métrica de la puntuación. Las métricas ausentes en los datos (por ejemplo, MC/DC en una ejecución lcov simple) simplemente se omiten.

El código objeto y la puntuación de mutación pesan 0 hasta que usted decida lo contrario (whmWeights.objectCode, whmWeights.mutation). La cobertura de código objeto engloba la cobertura de sentencias, de modo que ponderar ambas cuenta dos veces la misma evidencia; una puntuación de mutación no es cobertura en absoluto: un conjunto de pruebas puede ejecutar todas las líneas y no detectar nada. Aun así, ambas tienen su propia columna y su propio umbral.

Screenshot pending — add assets/img/score-weights.svg (see SCREENSHOTS.md).

Cobertura de condiciones

a && b es una decisión —dos ramas— y dos condiciones con cuatro resultados. Un conjunto de pruebas puede tomar ambas ramas sin ver nunca b como falso: la cobertura de ramas es completa y la cobertura de condiciones es de tres sobre cuatro. Ese nivel se sitúa entre la cobertura de ramas y MC/DC en DO-178C e ISO 26262, y desde la versión 0.2026.83 es una métrica propia en lugar de quedar integrada en las ramas: una fila en las tarjetas de la barra de estado, una columna en la vista Coverage, en los informes y en las exportaciones, un peso de 3 en la puntuación (whmWeights.conditions) y una puerta (threshold.conditions; sin puerta en el perfil standard, 100 en safety).

Screenshot pending — add assets/img/branch-condition-mcdc.svg (see SCREENSHOTS.md).

Se lee de las sondas condition de BullseyeCoverage, de una exportación cond de TRACE32 y de GCC 14 compilado con -fcondition-coverage. Un informe que no distingue las condiciones de las decisiones no tiene esa fila, esa columna ni ese peso. Si utiliza Bullseye o TRACE32: las condiciones contaban antes como ramas, por lo que su porcentaje de ramas cambia con esta versión y, con el nuevo peso, también su puntuación compuesta; establezca whmWeights.conditions en 0 para obtener la puntuación tal como era.

GCC 14, línea a línea. -fcondition-coverage hace que gcov diga qué resultado de qué condición falta — la condición 1 nunca verdadera, la condición 0 nunca verdadera ni falsa — y cada condición se marca en su línea y se nombra en la información al pasar el cursor, tanto desde el JSON de gcov como desde su listado de texto (condition outcomes covered 3/6). La métrica está donde están las demás: threshold.conditions le pone una puerta y queda sin juzgar donde una ejecución no tiene esa cifra, Copy Coverage Summary tiene una columna Conditions, badge.metric admite conditions, y el cuadro de búsqueda admite conditions < 80. La cifra de ramas de una función deja fuera los resultados de sus condiciones, igual que la del archivo y la de la ejecución.

Screenshot pending — add assets/img/gcc-conditions.png (see SCREENSHOTS.md).

Complejidad y CRAP

Algunos informes contienen la complejidad ciclomática de cada función: OpenCover (que es lo que escribe Coverlet), JaCoCo, Clover y Cobertura. Cuando es así, la extensión calcula una puntuación CRAP —Change Risk Anti-Patterns— para la función, a partir de esa complejidad y de la cobertura que ella misma midió:

CRAP = complexity² × (1 − coverage)³ + complexity

Una función sencilla y completamente probada obtiene su propia complejidad y nada más; una compleja y apenas probada obtiene una puntuación de varios cientos. En el ejemplo de C# del proyecto de demostración, Price() tiene una complejidad de 22 y alrededor del 37% de sus líneas cubiertas, lo que da 142.2, mientras que Shipping() tiene una complejidad de 12 y está completamente cubierta, lo que da 12. El límite habitual es 30: una función que lo alcanza o lo supera aparece bajo Riskiest Methods en el informe HTML, empezando por la peor.

Screenshot pending — add assets/img/crap-curve.svg (see SCREENSHOTS.md).

La complejidad y la puntuación figuran en el CodeLens de la función y junto a la función en el código fuente anotado. Max CRAP es la puntuación más alta de cualquier función de un archivo —la peor, no un promedio— y es una columna en la vista Coverage, en el informe HTML y en las exportaciones CSV y Markdown. Es información: no tiene umbral ni peso en la puntuación compuesta. Los informes que no contienen complejidad (lcov, gcov, Istanbul, coverage.py) no tienen CRAP, ni tampoco una columna vacía.

Desde la versión 0.2026.83, C y C++ también la tienen. llvm-cov no informa de ninguna complejidad, así que se cuenta a partir de los datos de ramas que el informe ya contiene: las condiciones escritas en el propio archivo de la función, más uno; es la definición de McCabe, y lo que cuentan las herramientas a nivel de código fuente para .NET y Java. Las condiciones que proceden de una macro de otro archivo —cada assert, por ejemplo— no se cuentan.

Screenshot pending — add assets/img/riskiest-methods.png (see SCREENSHOTS.md).

Risk hotspots, y qué archivos mostrar

Bajo el árbol de la vista Coverage, Risk hotspots enumera las funciones en las que el código complejo se encuentra con poca cobertura, de peor a mejor, cada una abriendo su archivo en la función. Una función entra por su puntuación CRAP — hotspots.crapThreshold, 30 por defecto, la cifra que propusieron los autores de la métrica — o solo por complejidad ciclomática, hotspots.complexityThreshold, desactivado por defecto; solo los informes que incluyen la complejidad (OpenCover, Cobertura de Coverlet, JaCoCo, llvm-cov) tienen alguno. Community ve el recuento y la peor puntuación; la lista ordenada es Pro. Junto a la ordenación, un segundo desplegable dice qué archivos muestra el árbol — todos, los archivos con huecos, los archivos sin probar o los archivos cambiados desde la última ejecución; las carpetas siguen a sus archivos y conservan sus propios números. Ambos están también en Visual Studio, en la ventana Coverage.

Screenshot pending — add assets/img/vs-hotspots.png (see SCREENSHOTS.md).

Espacios de nombres, clases y métodos

Para un informe .NET que nombra sus clases — Cobertura y el coverage.cobertura.xml de Coverlet, OpenCover — un tercer desplegable, Folders / Namespaces, dibuja la misma ejecución como espacios de nombres, clases y métodos: el número de un espacio de nombres es la suma de los de sus clases, el de una clase la suma de los de sus métodos, exactamente como el de una carpeta es la suma de los de sus archivos, con la misma ordenación y el mismo filtro. Una fila de método abre el archivo en el método; una clase declarada sin espacio de nombres está bajo (no namespace). La elección se escribe en coverageView.perspective; una ejecución que no trae nombres de clases no tiene desplegable y muestra sus carpetas. En Visual Studio la ventana Coverage tiene el mismo desplegable.

Screenshot pending — add assets/img/namespace-perspective.png (see SCREENSHOTS.md).

Buscar en el árbol

Bajo los botones y los desplegables, un cuadro de búsqueda. Una palabra conserva las filas cuyo nombre o ruta la contiene — cada palabra escrita tiene que estar ahí; una comparación conserva las filas cuya cifra la cumple — < 80% sobre la puntuación, lines >= 90, branches = 0, functions != 100, mcdc < 50 — e invoice < 80 exige ambas cosas. Las filas de método de la perspectiva de espacios de nombres y los risk hotspots se buscan junto con los archivos, de modo que una función se encuentra donde la tiene la ejecución. El árbol se filtra mientras escribe, en la página, sin redibujar; una carpeta que contiene una coincidencia se abre para ella y se vuelve a cerrar cuando el cuadro se vacía; Esc lo limpia. El mismo cuadro, la misma gramática, en Visual Studio.

Screenshot pending — add assets/img/tree-search.gif (see SCREENSHOTS.md).

El árbol sigue al editor

El archivo que está mirando se resalta en la vista Coverage, las carpetas que lo contienen se abren y su fila se desplaza hasta quedar a la vista — ya no hay que buscar en el árbol el archivo que ya está abierto. Por lo demás, el árbol conserva su posición de desplazamiento, y nada se vuelve a dibujar. coverageView.followActiveEditor, activado por defecto, lo desactiva para quienes prefieran dejar el árbol donde lo pusieron.

Screenshot pending — add assets/img/follow-editor.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-follow-editor.gif (see SCREENSHOTS.md).

11. Control de cumplimiento

El veredicto COMPLIANT / NON-COMPLIANT (que se muestra en la vista de fuente anotada, el informe HTML y ambas ventanas emergentes de la barra de estado) se determina mediante umbrales por métrica y un modo:

Screenshot pending — add assets/img/statusbar.png (see SCREENSHOTS.md).

Un umbral de 0 desactiva esa puerta, y una métrica que el informe no contiene nunca se juzga. Lo que representa un umbral que usted no ha establecido lo decide el perfil que figura más abajo. Ejecute Fucini Coverage: Check Coverage Thresholds para evaluar bajo demanda.

Screenshot pending — add assets/img/vs-error-list.png (see SCREENSHOTS.md).

Perfiles de umbrales

threshold.profile decide qué valor representa un umbral que usted no ha establecido. standard, el valor predeterminado desde la versión 0.2026.82, es lo que se le puede exigir a un proyecto corriente que no está relacionado con la seguridad funcional. safety pone todas las puertas en 100: lo que pide un caso de seguridad, y exactamente lo que se distribuía hasta la versión 0.2026.81.

Un umbral que usted sí ha establecido prevalece sobre cualquiera de los perfiles. El ejemplo fija la puerta de las ramas en 90 y todo lo demás en 100; para exigir 100 solo a algunas métricas, permanezca en standard y establezca esas usted mismo. Una salvedad se deriva de cómo funcionan los ajustes: un valor igual al predeterminado de fábrica no se puede distinguir de la ausencia de valor, de modo que con safety un umbral escrito exactamente con su cifra estándar —80 para las líneas, por ejemplo— sigue contando como 100.

{
  "fuciniCoverage.threshold.profile": "safety",
  "fuciniCoverage.threshold.branch": 90
}

Screenshot pending — add assets/img/threshold-profile.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/threshold-profiles.gif (see SCREENSHOTS.md).

Si confiaba en los valores predeterminados antiguos, se le juzgará con más indulgencia tras actualizar a la versión 0.2026.82 hasta que seleccione safety. A una instalación que ya se había utilizado antes se le indica una sola vez, con un botón Keep 100% (safety) que escribe el perfil en sus ajustes de usuario; en un proyecto compartido, póngalo también en los ajustes del área de trabajo, para que a todos se les juzgue por igual. Configure Coverage Compliance & Thresholds... muestra el perfil encima de la cuadrícula de umbrales, y su vista previa en vivo juzga con las puertas realmente vigentes. En todas las tarjetas e informes, una métrica cuya puerta está desactivada muestra su cifra con un guion neutro en lugar de una marca de verificación o una cruz.

Screenshot pending — add assets/img/statusbar-metrics.png (see SCREENSHOTS.md).

11a. Cobertura de código objeto

Todas las demás métricas aquí se miden desde el código fuente: una herramienta instrumenta su código, la compilación instrumentada se ejecuta y los contadores dicen qué sentencias, ramas o condiciones se ejercitaron. La cobertura de código objeto mide otra cosa: cuánto del binario construido se ejecutó realmente, contado en bytes de instrucciones, observando el flujo de instrucciones en lugar de instrumentar el código fuente. Importa porque un compilador emite código del que ninguna línea de su fuente da cuenta: comprobaciones de límites de arrays, tablas de salto de switch, volcados de registros, sondas de pila, llamadas a rutinas auxiliares de ejecución para división o coma flotante en núcleos que carecen de la instrucción. Es además la única métrica aquí que responde a ¿esto cubre el ensamblador? — el ensamblador escrito a mano nunca se instrumenta y una herramienta basada en la fuente no llega a él. DO-178C es explícito sobre el motivo: en el nivel A, cuando un compilador o enlazador genera código que no es directamente trazable a sentencias del código fuente, el objetivo 6.4.4.2b exige verificación adicional exactamente de ese código generado.

Subsume la cobertura de sentencias: toda instrucción ejecutada provino de una sentencia, así que un 100% de cobertura de código objeto implica un 100% de cobertura de sentencias. Lo contrario no se cumple, y esa asimetría es justamente el motivo de medirla. De ahí se siguen dos cosas. No tiene ningún peso en la puntuación compuesta, porque promediar dos medidas de las mismas ejecuciones cuenta la misma evidencia dos veces; en su lugar se controla mediante fuciniCoverage.threshold.objectCode, un requisito en vez de un peso, que es como lo pide la norma. Y la diferencia es el entregable: una ejecución con 100% de cobertura de líneas y menos del 100% de cobertura de código objeto ha localizado exactamente el código generado por el compilador del que su fuente no da cuenta, por lo que la ficha de cumplimiento dice 312 bytes nunca ejecutados, con 100% de cobertura de líneas en lugar de esconderlo como «94%». Lo inverso —un binario entero dado por ejecutado mientras su fuente no lo estaba— es una contradicción y no una puntuación baja: casi siempre un archivo de traza obsoleto en un lado de una fusión, o nombres de módulos que nunca coincidieron con rutas de archivo. Se informa como hallazgo.

La cobertura de código objeto exige que el binario se ejecute donde puedan observarse sus instrucciones. Hay tres vías y difieren enormemente en coste. Solo la tercera produce cobertura de código objeto; las dos primeras aparecen porque resuelven un problema afín que a menudo es el que de verdad conviene resolver.

1. Una compilación instrumentada, ejecutándose en el destino. Los compiladores cruzados de GCC aceptan -fprofile-arcs -ftest-coverage, así que la instrumentación que funciona en una estación de trabajo funciona en el destino, salvo que un sistema bare-metal no tiene sistema de archivos donde escribir los contadores .gcda, y a menudo no tiene exit() en el que escribirlos. Los contadores viven en RAM de todos modos, así que la solución es volcar esa memoria y reconstruir los archivos fuera del destino; embedded-gcov de la NASA JPL (Apache-2.0) hace exactamente eso, sin sistema de archivos, sistema operativo ni biblioteca C estándar. Esto da cobertura de sentencias, ramas y funciones de una compilación hecha por su compilador cruzado, para su juego de instrucciones, sobre su hardware — no cobertura de código objeto, y el binario medido está instrumentado, por tanto más grande y más lento que el que usted entrega. Cargue el resultado como LCOV, gcovr JSON, gcov JSON o, en una cadena de herramientas anterior a GCC 9, como el listado de texto .gcov.
2. Un simulador del juego de instrucciones. Ejecute el binario real de destino en un simulador y derive la cobertura de las direcciones ejecutadas: sin hardware, sin instrumentación, sin sonda y, como observa instrucciones, puede producir cobertura de código objeto genuina. El límite es la fidelidad: un simulador modela bien el núcleo y peor los periféricos, así que trate con recelo los resultados de sistema completo salvo que modele su silicio con precisión.
3. Traza en chip y un depurador. La vía de grado de certificación, y la única realmente no intrusiva: la unidad de traza del núcleo comunica el flujo de instrucciones a un depurador, que lo convierte en cobertura. Nada se instrumenta, el tamaño del código no cambia y la temporización no se altera, que es lo que convierte el resultado en evidencia sobre el binario que realmente entrega. Compruebe el silicio antes de presupuestarlo: en muchas familias de microcontroladores la traza completa solo está disponible en una variante de emulación o desarrollo con un búfer de traza grande y un puerto de traza rápido, mientras que las piezas de producción exponen una unidad de traza reducida cuyo recurso alternativo del fabricante es una traza por software que instrumenta el código y consume tiempo de CPU, eliminando justamente la propiedad por la que se eligió esta vía.

Muchos proyectos embebidos miden la cobertura compilando las mismas fuentes para la máquina de desarrollo y ejecutando allí las pruebas unitarias. Es rápido, no necesita hardware y es la opción por defecto correcta para la mayoría de los equipos — pero conviene ser claro sobre lo que describe esa evidencia: un compilador distinto, un optimizador distinto, un juego de instrucciones distinto y un binario distinto del que se entrega. Para la mayoría del software eso es una concesión aceptable y bien entendida. Para trabajo evaluado según IEC 61508, ISO 26262 o DO-178C es la objeción estándar de host frente a destino, y las vías anteriores son las respuestas estándar a ella: la primera la cierra para la cobertura de fuente, la tercera para el código objeto.

Hoy por hoy, la exportación leída para el código objeto es la de COVerage.EXPORT.ListModule de Lauterbach TRACE32 con metric="object"; cárguela como cualquier otro archivo de traza. La métrica se puntúa y se controla solo con una licencia de pago y durante el período de evaluación. Una instalación Community no la puntúa, pero se le informa cuando un archivo de traza la contiene, porque un veredicto de cumplimiento que omitiera en silencio la evidencia más fuerte del archivo sería peor que uno que dice lo que omitió.

12. Exclusión de líneas sin código

Con excludeComments activado (valor predeterminado), las sentencias que caen íntegramente en líneas solo de comentario o en blanco quedan excluidas de los totales — esto también neutraliza una peculiaridad conocida de llvm-cov/gcov por la que un recuento de aciertos suelto recae en un comentario. También se respetan los marcadores estándar:

x = risky();          // LCOV_EXCL_LINE
// LCOV_EXCL_START
debug_only_block();
// LCOV_EXCL_STOP

Las directivas del preprocesador tampoco cuentan como código, en C, C++, Objective-C, CUDA y C#: una línea que empieza por # — #define, #include, #if — y las líneas a las que la prolonga una barra invertida final. gcov imputa cada uso de una macro a la línea en la que está definida, así que un encabezado cuya única línea registrada era #define CHANNEL_COUNT (33U) figuraba como cubierto al 100% porque un bucle del archivo .c llegaba hasta ese valor, y otro cuya constante nadie usaba figuraba al 0%. Un encabezado así ya no tiene nada que medir y no aparece en la lista.

Ponga excluded.includeInTotals en true para contar de todos modos las líneas excluidas.

Dejar fuera un archivo o una carpeta, desde el árbol

Haga clic con el botón derecho en un archivo o una carpeta de la vista Coverage y elija Exclude from Coverage — también está entre las acciones de ruta de la fila — o ejecute Exclude This File from Coverage sobre el archivo abierto: la ruta del archivo relativa al espacio de trabajo, o el /** de la carpeta, va a fuciniCoverage.ignore en la configuración de la carpeta, una vez, y la recarga lo saca de cada total y de cada página; el patrón queda ahí para poder quitarlo de nuevo. En Visual Studio el menú de la fila y Tools → Coverage Studio tienen los mismos dos comandos, que escriben el mismo ajuste en el mismo archivo.

Screenshot pending — add assets/img/exclude-from-tree.gif (see SCREENSHOTS.md).

Atributos y espacios de nombres, para .NET

Dos ajustes leen del código fuente lo que el informe no sabe decir. ignore.attributes — ExcludeFromCodeCoverage por defecto — excluye la clase, el método o la propiedad situados bajo un atributo que nombra, como lo haría LCOV_EXCL_START/STOP, sea cual sea la herramienta que escribió el informe: Coverlet respeta el atributo, OpenCover, dotCover y un lcov convertido no, y ahora todos coinciden. Nombres con o sin el sufijo Attribute, con o sin espacio de nombres; añada GeneratedCode, Obsolete o los suyos. ignore.namespaces deja fuera cada archivo cuya declaración de espacio de nombres coincide con un prefijo, * como comodín — Acme.Generated, Acme.*.Migrations, *Tests — y el panel Output nombra los archivos que quitó. Ambos se leen en la misma pasada que lee los marcadores de comentario, en las dos ediciones.

{
  "fuciniCoverage.ignore.attributes": ["ExcludeFromCodeCoverage", "GeneratedCode"],
  "fuciniCoverage.ignore.namespaces": ["Acme.Generated", "*.Migrations"]
}

Excluir desde el editor

Seleccione las líneas y tome Exclude Selection from Coverage de la bombilla, del menú contextual del editor o de la Command Palette — en Visual Studio la bombilla (Ctrl+.), el menú del botón derecho de la ventana de código, Tools → Coverage Studio o Ctrl+Shift+U, X — y la exclusión se escribe donde está el código: [ExcludeFromCodeCoverage] sobre una clase, un método o una propiedad de C#, VB o F#, con el nombre corto cuando el archivo ya importa System.Diagnostics.CodeAnalysis y con el nombre completo cuando no, para que no haya que añadir ningún using; LCOV_EXCL_LINE al final de una línea de código; LCOV_EXCL_START y LCOV_EXCL_STOP alrededor de varias, con la sangría de la primera — con el signo de comentario propio del lenguaje, //, #, ', -- o ;. Un solo paso de deshacer. La bombilla también lo ofrece en una línea que las entradas de Problems marcan como sin cubrir. Una línea ya marcada, o un miembro que ya tiene el atributo, se deja como está.

Screenshot pending — add assets/img/exclude-selection.gif (see SCREENSHOTS.md).

Solo las ramas, y los marcadores de gcovr

Un else defensivo, un default: al que no llega ningún valor, la rama que un compilador añade para una excepción: la línea se ejecuta y debe contar, y solo su rama no se puede tomar. LCOV_EXCL_BR_LINE y LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP sacan del recuento las ramas de sus líneas y dejan en él las líneas. LCOV_EXCL_EXCEPTION_BR_LINE y su región sacan aún menos — solo las ramas que toma una excepción, donde el informe dice cuáles son, como hace el JSON de gcov. Cada marcador se lee también con los prefijos de gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOVR_EXCL_BR_LINE, GCOV_EXCL_STOP y los demás significan lo mismo que los LCOV_EXCL_, de modo que un código fuente escrito para gcovr se lee igual aquí, sea cual sea la herramienta que generó el informe. No se lee: GCOVR_EXCL_FUNCTION — nada en esa línea dice dónde termina la función.

if (handle == NULL) return E_FAIL;   // LCOV_EXCL_BR_LINE: the allocator never fails on target
  // LCOV_EXCL_BR_START generated state table
  switch (state) { /* … */ }
  // LCOV_EXCL_BR_STOP

Screenshot pending — add assets/img/branch-markers.png (see SCREENSHOTS.md).

Decir por qué: exclusiones justificadas

Sacar código del recuento es una afirmación — «esto no se puede probar», «esto es una ayuda para el desarrollador» — y bajo DO-178C, ISO 26262 o IEC 61508 una afirmación que cambia la cifra en la que se apoya un certificado tiene que quedar por escrito y poder revisarse. Por eso una exclusión puede decir por qué, en el lugar donde está escrita: el texto que sigue a LCOV_EXCL_LINE o LCOV_EXCL_START, o la Justification de [ExcludeFromCodeCoverage].

abort();                 // LCOV_EXCL_LINE: defensive, unreachable by construction
  // LCOV_EXCL_START debug dump, never built for the target

  [ExcludeFromCodeCoverage(Justification = "a developer aid")]
  public static void DebugDump(decimal amount) { /* … */ }

Los motivos se leen en cada carga y el registro los cuenta. Export Coverage Report… escribe la lista — exclusiones y sus justificaciones, como Markdown o CSV: el archivo, las líneas, cómo se escribió la exclusión, y la justificación o none given. Un archivo al que no le queda nada medible sigue estando en esa lista. Con exclusions.requireReason activado, una exclusión que no da ningún motivo es un hallazgo: una advertencia en Problems en su línea, y un fallo de Check Coverage Thresholds. Exclude Selection from Coverage pide entonces primero el motivo y lo escribe con el marcador o como la Justification del atributo; si la petición se descarta o se deja vacía, no se excluye nada.

Screenshot pending — add assets/img/justified-exclusions.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-justified-exclusions.png (see SCREENSHOTS.md).

12a. ¿Esta cobertura sigue describiendo este archivo?

12b. No medido frente a no cubierto

{
  "fuciniCoverage.unmeasured.mode": "list",
  "fuciniCoverage.threshold.unmeasuredFiles": 0
}

Los archivos de cabecera son el falso positivo conocido en C: tienen la familia de extensiones de la ejecución y ningún archivo de traza nombrará nunca uno, porque por sí solo no compila a nada. Por eso fuciniCoverage.unmeasured.exclude deja fuera de forma predeterminada **/*.h, **/*.hpp, **/*.hh, **/*.inl y **/*.d.ts, con la misma sintaxis glob que fuciniCoverage.ignore; añada un port a otra plataforma que aquí no se compila, o stubs generados, y salen de la lista, del recuento y del estado de la barra de estado. Un archivo que ignore nombra tampoco se considera nunca no medido — dejarlo fuera era justamente la intención. threshold.unmeasuredFiles vale -1 de forma predeterminada, lo que no comprueba; 0 falla en cuanto algún archivo del tipo de la ejecución nunca fue cargado por una prueba, y solo se aplica mientras unmeasured.mode es list o count.

13. Informes HTML

• Generate Full HTML Report — un informe autorrenderizado, multipágina, por directorio. La salida va a htmlReport.outputDir, o al almacenamiento global de la extensión si no se establece.
• Open Annotated Source — una vista anotada de un solo archivo. Apunte externalHtmlReport.dir a un directorio llvm-cov show --format=html preconstruido para usar esas páginas en lugar del renderizador integrado.
• Export Fucini JSON — el modelo normalizado completo para sus propias herramientas.
• Export Coverage Report... — la ejecución como CSV (por archivo o por función), resumen en Markdown, archivo LCOV, XML de Cobertura, SARIF, o insignia SVG autónoma para su README. También accesible desde el botón junto a Generate Full HTML Report en la vista Covered Files. Todo salvo los CSV pierde información — MC/DC, regiones e instanciaciones no caben en LCOV, Cobertura ni SARIF — así que Fucini JSON y los CSV siguen siendo los formatos que llevan todas las métricas.
• Copy Uncovered Lines — un resumen en Markdown de cada hueco, listo para pegar en una PR.

Screenshot pending — add assets/img/vs-annotated-source.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-directory-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-file-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-coverage-gaps.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-mcdc-detail.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/export-picker.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/annotated-source.png (see SCREENSHOTS.md).

Fuente anotada frente a fuente normal

Open Annotated Source reemplaza la pestaña activa por una vista web de cobertura codificada por colores para ese archivo, en la misma columna; Open Annotated Source to the Side hace lo mismo pero dividido, de modo que el código fuente y la vista anotada quedan uno junto al otro. Para alternar entre ambos en el mismo lugar —útil en pantallas pequeñas, donde una división deja cada panel demasiado estrecho— use Toggle Annotated Source: alterna la pestaña activa entre los dos, recordando cuál está viendo en ese momento. Desde la propia vista anotada, Show Source vuelve directamente al editor normal de ese archivo.

El HTML que realmente ve depende de externalHtmlReport.dir: cuando está definido y ya existe allí una página que coincide con el archivo activo (llvm-cov organiza las páginas por archivo como <nombre-repo>/<ruta-relativa>.html, por lo que nunca hace falta configurar la carpeta del nombre del repositorio del informe), se muestra esa página generada por la cadena de herramientas en lugar del renderizador integrado — sus enlaces/hoja de estilo locales se reescriben para funcionar dentro de la vista web, y contiene detalles que la vista integrada no reproduce (vistas de expansión MC/DC, resaltado de regiones, resúmenes por directorio). ¿No hay página coincidente para ese archivo, o el ajuste está vacío? Entonces se usa el renderizador integrado. La extensión solo lee este directorio; nunca escribe en él.

Una insignia de cobertura para el README

Generate Coverage Badge escribe un SVG al estilo de shields para la ejecución activa en el espacio de trabajo — badge.outputPath, de forma predeterminada coverage-badge.svg, relativo a la carpeta del espacio de trabajo o absoluto, con las mismas variables que cualquier otro ajuste de ruta — y ofrece abrirlo. Es un archivo corriente en su repositorio, así que un README lo incrusta sin ningún servicio detrás, sin ninguna ida y vuelta a shields.io, y funciona también en un repositorio sin conexión a la red:

![coverage](coverage-badge.svg)

badge.metric elige lo que muestra la insignia: lines (etiquetada coverage), branches, mcdc o weighted, la misma puntuación compuesta que muestra la barra de estado, etiquetada score. Una ejecución sin datos para la métrica elegida recibe un n/a gris en lugar de un 0% rojo. El color sigue sus propios niveles de colorScale.*: lowColor por debajo de lowThreshold, midColor hasta highThreshold, highColor a partir de ahí. Con badge.autoUpdate activado, la insignia se reescribe tras cada carga correcta, en silencio, y el canal de salida registra cada escritura como [FUCINI_BADGE] — desactivado de forma predeterminada porque escribe en el espacio de trabajo en cada carga. Confirme el SVG junto con el código y la imagen de la página del repositorio sigue a la cifra del editor.

{
  "fuciniCoverage.badge.outputPath": "docs/coverage-badge.svg",
  "fuciniCoverage.badge.metric": "weighted",
  "fuciniCoverage.badge.autoUpdate": true
}

14. Historial y tendencias

Active history.enabled para conservar las ejecuciones localmente (manteniendo history.retention de ellas). Después obtendrá una flecha de tendencia (▲/▼) en la barra de estado, el gráfico de tendencia en la vista Coverage y dos comandos de comparación: Compare with Last Run y Compare Two History Runs, cada uno de los cuales genera una diferencia de regresión/mejora por archivo.

Screenshot pending — add assets/img/history-compare.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/since-last-run.png (see SCREENSHOTS.md).

El gráfico de tendencia

Bajo la barra de herramientas de la vista Coverage, con dos o más ejecuciones guardadas, la cobertura de líneas del historial como una línea, de la más antigua a la más reciente, las treinta últimas: un punto por ejecución que dice su fecha y su cifra al pasar el cursor, y la última cifra al lado con una flecha para la dirección desde la primera. La escala vertical es el propio rango de las ejecuciones, así que un equipo al 92–94% ve el movimiento en lugar de una línea plana por debajo de 100. Ambas ediciones lo dibujan a partir del mismo historial.

Screenshot pending — add assets/img/trend-chart.png (see SCREENSHOTS.md).

Sesiones de cobertura

Una sola ejecución de pruebas rara vez cubre todo lo que tocó un cambio: las pruebas unitarias corrieron aquí, el conjunto de integración allí, un recorrido por la interfaz con la cobertura activada en otro sitio. Start Coverage Session convierte las cargas que siguen en una sola suma — cada ejecución se añade a la anterior línea a línea como unión: una línea que cualquiera de ellas ejecutó está cubierta y los recuentos se suman —, de modo que el margen, el árbol y la puntuación muestran lo que alcanzaron todas juntas. La ejecución en pantalla, si la hay, es la primera de la sesión. Una barra sobre el árbol dice cuántas ejecuciones desde cuándo y termina la sesión; End Coverage Session hace lo mismo, y la siguiente carga vuelve a estar sola. En Visual Studio una sola entrada en Tools → Coverage Studio inicia la sesión y, marcada, la termina.

Screenshot pending — add assets/img/coverage-session.gif (see SCREENSHOTS.md).

La línea base de CI: ¿dónde estoy respecto a main?

Compare with Last Run responde a qué hizo su último cambio; antes de una pull request la pregunta es dónde está respecto a main, y la respuesta está en el servidor de compilación. baseline.report nombra el informe que publica la compilación de la rama main, y cada carga se compara con él: la tarjeta de la barra de estado lleva el delta en una línea — vs CI baseline: 84.20% → 85.10% (+0.90%), 3 file(s) moved — y Compare with CI Baseline enumera los archivos que se movieron, archivo por archivo, con las mismas palabras que Compare with Last Run. En Visual Studio el comando está en Tools → Coverage Studio y descarga o lee el informe cuando usted lo pide. Tres maneras de nombrarlo, en .vscode/settings.json:

{
  "fuciniCoverage.baseline.report": "https://gitlab.example.com/api/v4/projects/42/jobs/artifacts/main/raw/coverage/lcov.info?job=test",
  "fuciniCoverage.remote.headers": ["PRIVATE-TOKEN: ${env:GITLAB_TOKEN}"]
}

Sirve cualquier formato que el lector conozca. Una ruta que la CI escribió relativa a su checkout — src/Billing/Invoice.cs, como la escribe Coverlet en el runner — se sitúa bajo esta carpeta antes del diff, para que coincida con el archivo que resolvió la ejecución local; una ruta absoluta de otra máquina no coincide con nada, así que haga que la canalización escriba rutas relativas. Una línea base que no se puede descargar ni leer es una línea en el panel Output, nunca una carga fallida.

Screenshot pending — add assets/img/ci-baseline.gif (see SCREENSHOTS.md).

Un artefacto es un zip, y eso también se lee. GitHub y GitLab entregan un artefacto como un archivo comprimido, se haya puesto en él lo que se haya puesto. Nombre el informe que contiene después de un #: el miembro se encuentra por su ruta o por el final de ella; sin #, es el único archivo del comprimido, o su único archivo que parece un informe, y donde hay varios el panel Output los nombra. Lo mismo vale para un zip que usted descargó (ci/artifact.zip#lcov.info) y, en VS Code, para una URL en coverageFile.paths. El token va al servidor para el que se configuró y no más allá: la redirección al almacenamiento que guarda el archivo comprimido se sigue sin él.

{
  "fuciniCoverage.baseline.report": "https://api.github.com/repos/acme/app/actions/artifacts/1234567/zip#coverage/lcov.info",
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:GITHUB_TOKEN}"]
  }

14a. Para agentes de IA: la cobertura en pantalla

Un agente que escribe pruebas puede ejecutarlas y leer un porcentaje. Lo que no puede hacer por sí solo es preguntar lo que sabe el editor: qué líneas de esta función nunca se ejecutaron, qué lado de qué rama, qué pruebas alcanzan una línea, si el diff que acaba de escribir está cubierto. Seis herramientas responden exactamente a eso, con palabras sobre las que un agente puede actuar, a partir de la ejecución cargada — las mismas exclusiones, el mismo remapeo, los mismos números que en pantalla. Así, un agente al que se le pide cubrir los huecos de una función y un revisor que mira el margen hablan de las mismas líneas.

El propio agente de VS Code las tiene como herramientas sin configurar nada. Todos los demás agentes — cualquier cliente que hable MCP, el Model Context Protocol — acceden a ellas a través de un servidor que el editor ejecuta cuando mcp.enabled está activado, tanto en VS Code como en Visual Studio. Copy MCP Server Configuration pone la entrada del cliente en el portapapeles, tal como VS Code y Visual Studio la leen en un mcp.json; un cliente que llama mcpServers a la clave exterior toma la misma entrada bajo ese nombre.

Screenshot pending — add assets/img/mcp-config.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mcp-config.png (see SCREENSHOTS.md).

{
  "servers": {
    "fucini-coverage": {
      "type": "http",
      "url": "http://127.0.0.1:39217/mcp",
      "headers": { "Authorization": "Bearer …" }
    }
  }
  }

• Está desactivado mientras usted no lo active, y solo escucha en 127.0.0.1: nada de fuera de esta máquina llega a él.
• Una llamada tiene que llevar el token de usted, creado una vez y guardado para usted; sin él, la respuesta es 401. La configuración copiada lleva el token: manténgala fuera del repositorio.
• Una llamada enviada por una página web — lo dice en su Origin — se rechaza, lleve lo que lleve.
• Lee la ejecución cargada y no escribe nada. La ejecución de pruebas se nombra, no se inicia: el agente ejecuta el comando en su propio terminal.

El puerto es mcp.port, 39217 si no se indica otro. Donde ese está ocupado — una segunda ventana, la otra edición junto a esta — se usa el siguiente libre, y la configuración copiada nombra el que funciona. El panel Output dice dónde escucha el servidor ([FUCINI_MCP]) y por qué no pudo hacerlo ([FUCINI_MCP_001]). Lo que un plan no incluye — los nombres de las pruebas, el detalle de MC/DC — las herramientas lo cuentan sin detallarlo, como hace la información al pasar el cursor.

15. Referencia de comandos

Screenshot pending — add assets/img/statusbar-and-toolbar.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/statusbar-menu.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/worst-functions.png (see SCREENSHOTS.md).

16. Referencia de configuración

La tabla completa y categorizada de ajustes — cada opción con su valor predeterminado — se encuentra en la página Features & Settings. Todas las claves tienen el prefijo fuciniCoverage..

Cabe destacar: fuciniCoverage.language fija la propia interfaz en tiempo de ejecución de esta extensión (barra de estado, notificaciones, información sobre herramientas, vistas web) a un idioma concreto, independientemente del idioma de visualización de VS Code — por defecto es auto e incluye paquetes para los 18 idiomas admitidos. No cambia las entradas de la paleta de comandos ni las etiquetas de la configuración, que VS Code resuelve a partir de su propio idioma de visualización.

17. Códigos de error

Los diagnósticos se envían al canal de salida Fucini Coverage (View → Output → Fucini Coverage), cada uno con un código estable FUCINI_*.

18. Privacidad

La telemetría se controla mediante el ajuste telemetry.enabled de ámbito window. Está desactivada de forma predeterminada. El resumen diario y el aviso de eliminación requieren además que el telemetry.telemetryLevel global de VS Code permita la telemetría; el aviso de instalación y algunos eventos pequeños se envían en cualquier caso, al igual que la entrada en el libro de uso de una instalación en el periodo de prueba o en el nivel gratuito Community. En Community, Unlock Full Features canjea esta telemetría por todas las funciones Pro, MC/DC incluida, durante 30 días, una vez por máquina; desactívala de nuevo y se aplica el conjunto estándar de Community. Una licencia de pago no se ve afectada en ningún caso. Consulta la política de privacidad para saber qué se envía.

Dos cosas conviene conocer, porque puedes actuar sobre ellas. La primera es tu ID del libro de uso: en la prueba y en Community, la extensión lo muestra en Show License / Activation y al final de What Community Includes, donde al seleccionar la fila se copia y se abre la política de privacidad. El libro conoce tu máquina por un hash y por nada más, así que ese ID es la única manera de preguntar qué guarda sobre ti, pedir que se elimine u oponerte a él: cítalo y encontraremos tu fila; sin él no podemos. La segunda es el registro de instalación: una fila escrita la primera vez que una instalación informa y conservada en lugar de eliminarse a los 90 días, con el identificador de instalación, el día, el lugar al que se resolvió su dirección, las versiones y el sistema operativo; no la dirección en sí, ni nada sobre tu código. Es lo que nos permite decir cuántas instalaciones ha habido a lo largo de los años. Ambos se describen por completo en la política de privacidad, y ambos se eliminan si lo pides.

19. Evaluación y activación

Fucini Coverage Studio se distribuye como preversión de evaluación. En la primera ejecución se te pide aceptar evaluarla y comienza la prueba: todas las funciones están disponibles durante una prueba de 14 días, contados desde la primera vez que la usas en esa instalación. No hay una fecha fija tras la cual deje de funcionar algo.

A partir de la versión 2.2026.2, la prueba de una instalación nueva comienza en cuanto la extensión ha contactado una vez con el servidor de licencias; hasta entonces funciona en el nivel Community y lo indica. En un contenedor de desarrollo o un Codespace no comienza ninguna prueba: un código de suscripción, una clave o el pase de 7 días desbloquea allí el conjunto completo.

Cuando termina la prueba no se bloquea nada: la extensión pasa al nivel gratuito Community. Para recuperar el conjunto completo, actívala: la activación se conecta al servidor de licencias y aplica la clave devuelta automáticamente, sin correo y sin ninguna clave que copiar a mano:

Screenshot pending — add assets/img/licence-dialog.png (see SCREENSHOTS.md).

1. Ejecuta Fucini Coverage: Show License / Activation (también accesible desde la barra de estado una vez caducada la prueba o la clave) y haz clic en Request License… (o Request Renewed Key… si ya activaste antes).
2. Confirma la solicitud. La clave se emite automáticamente y se reutilizan tus datos de contacto de cualquier solicitud anterior en lugar de volver a pedirlos.
3. Ya está. La clave de activación se genera y se escribe automáticamente en fuciniCoverage.license.key. La barra de estado pasa de la prueba a una licencia activada en un momento.

La vía manual en una imagen: abra el panel de licencia, elija Enter Key, pegue la clave de su correo y el banner pasa a «Activated».

Screenshot pending — add assets/img/activate-key.gif (see SCREENSHOTS.md).

{ "fuciniCoverage.license.key": "FCK1.…pegue aquí la clave completa…" }

El nivel gratuito Community: una cuota semanal

Community nunca deja de mostrar la cobertura. Los márgenes, la regla de vista general, los hovers, CodeLens, la vista Coverage, el modo watch, la cobertura de diff y el historial no se cuentan en absoluto, y cargar un tracefile mediante un comando solo está limitado a 25 al día. Lo que se mide es la salida: cinco a la semana de cada una de estas acciones: abrir el informe HTML, exportar, comparar dos ejecuciones, comprobar los umbrales y ver el código fuente anotado en el sitio.

La semana es suya, no del calendario: empieza con el primer uso y termina siete días después. Cuando una cuota se agota, el mensaje nombra la acción y el día en que vuelve, y después de ese único mensaje solo la barra de estado lo menciona. Fucini Coverage: What Community Includes enumera cada cuota, con cuánto se ha usado y cuándo se restablece, antes de que llegue a alcanzar alguna.

Screenshot pending — add assets/img/weekly-allowance.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-limit-prompt.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-includes-weekly.png (see SCREENSHOTS.md).

Tres detalles pertenecen a los planes de pago, mientras que sus hallazgos siguen siendo gratuitos: Community marca cada línea que tiene mutantes supervivientes y dice cuántos, pero no qué cambió cada mutante; dice cuántas pruebas ejecutaron una línea, pero no sus nombres; y muestra el Max CRAP de una ejecución, pero no la lista clasificada Riskiest Methods.

Screenshot pending — add assets/img/mutant-hover-community.png (see SCREENSHOTS.md).

Si ya usaba Community cuando llegó la cuota semanal (0.2026.83), sus límites anteriores se mantienen durante 30 días; se le avisa una sola vez, con la fecha. Los contadores se guardan en su equipo —en el almacenamiento propio de VS Code y en ~/.fucini-coverage/, de modo que un perfil nuevo de VS Code continúa la misma semana— y nunca se envían a ningún sitio.

El pase de 7 días

¿No está listo para una suscripción? Un pase de 7 días es todo lo de Pro durante una semana, pagado una sola vez: nada se renueva y no hay nada que cancelar. Cómprelo en la página de precios (el mensaje que aparece al alcanzar un límite de Community tiene un botón para ello), y el código de activación llega por correo electrónico.

Screenshot pending — add assets/img/pricing-week-pass.png (see SCREENSHOTS.md).

1. Ejecute Fucini Coverage: Enter Subscription Code: el comando existe tanto en la edición Community como en Pro.
2. Elija Pro y pegue el código FCB1-… del correo.
3. Eso es todo. La clave se emite y se aplica por usted, y funciona sin conexión. La semana cuenta desde el pago, así que active en cuanto compre. Cuando termina, la extensión vuelve por sí sola a Community y sigue mostrando la cobertura.

Screenshot pending — add assets/img/pass-step-plan.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/pass-step-code.png (see SCREENSHOTS.md).

Cambiar de ordenador y gestionar los puestos

Una clave está ligada a una máquina, así que un ordenador nuevo necesita una nueva — y tu suscripción no paga más máquinas de las que indica. Libera la anterior tú mismo: entra en gestionar tu suscripción, busca el puesto que ya no usas, elige Free up y activa la máquina nueva con el mismo código. Comprar Pro no te envía ninguna contraseña: tu cuenta existe, simplemente aún no tiene una, así que la primera vez usa establecer o restablecer tu contraseña con la dirección con la que te suscribiste.

En Business y Enterprise invitas a cada compañero por correo desde esa misma página. Cada uno recibe un código de activación que es solo suyo, y en cuanto lo usa su dirección aparece junto a su puesto: cuando alguien se va, ves cuál era el suyo y lo liberas para el siguiente. Una invitación ocupa un puesto desde que la envías y caduca a los 14 días si no se usa; retírala para recuperar la plaza al instante.

Probar versiones preliminares

Las novedades llegan a fucini.software antes que al Marketplace, y puede pedir que se las ofrezcamos. Abra la vista Coverage, despliegue el panel de licencia y pulse Probar versiones preliminares… — o active fuciniCoverage.update.preRelease. A partir de ahí, la extensión consulta aquí un canal preliminar aparte además del habitual, y ofrece la más reciente de las dos.

Screenshot pending — add assets/img/licence-prerelease.png (see SCREENSHOTS.md).

Las versiones preliminares están probadas, pero son las compilaciones de las que menos seguros estamos: estaría ofreciéndose voluntario para encontrar lo que se nos escapó. Al unirse nos dice que esta instalación está en el canal, de modo que sabemos cuántas personas están probando y podemos contarle qué ha cambiado; al salir, la siguiente versión estable le devuelve al camino habitual. No siempre hay una versión preliminar disponible, y unirse cuando no la hay no cuesta nada: la extensión encuentra un canal vacío, no dice nada al respecto y sigue ofreciendo versiones estables hasta que se publique una.

Screenshot pending — add assets/img/licence-prerelease-joined.png (see SCREENSHOTS.md).

20. Contacto y licencia

Preguntas, informes de errores o condiciones de licencia alternativas — consulte la página de contacto o escriba a info@fucini.consulting. Con licencia MIT con una condición de atribución en las notas de la versión; véase también el Notice.

21. En la línea de comandos

El lector también funciona sin editor: npm install -g fucini-coverage, gratis, en Windows, Linux, WSL y macOS. fucini-coverage check coverage/lcov.info --lines 80 es la puerta con la que falla una canalización; summary, export, report, badge y compare hacen lo que hacen los comandos de los editores con esos nombres, y mcp sirve las seis herramientas de la sección anterior a un agente, en un servidor. Lee fucini-coverage.json, el archivo de configuración que lee la edición para Visual Studio, así que los umbrales se fijan una sola vez. fucini-coverage help <command> explica cada uno; la página completa es fucini-coverage en npm.

Screenshot pending — add assets/img/cli-demo.gif (see SCREENSHOTS.md).