Registo de alterações

Corrigido

• A pasta onde inicia o comando não decide o que um relatório significa. A 2.2026.3 ancora os caminhos relativos de um relatório na pasta onde esse relatório foi escrito — mas só para um comando iniciado noutro sítio. Executado a partir da raiz da árvore que mede, que é onde um comando de cobertura é normalmente executado, um caminho relativo continuava a ser respondido por essa pasta, e um ficheiro que o llvm-cov já tinha nomeado por inteiro era contado uma segunda vez: uma árvore de 5258 linhas lia-se como 5836. Agora decidem apenas o --cwd e a localização do próprio relatório. A mesma correção está nos dois editores, onde a pasta era aquela a partir da qual o VS Code ou o Visual Studio tinha sido iniciado.
• O export --format json escrevia a execução por cima das suas definições. O seu ficheiro era fucini-coverage.json — o nome de onde as definições são lidas — pelo que, numa pasta configurada da maneira habitual, a exportação destruía os limiares por que acabara de julgar. A execução é escrita em coverage-run.json, e o export e o badge recusam um --out que nomeie o ficheiro de definições.
• O --cwd aceita uma pasta, escreva-a como a escrever. Uma relativa — --cwd ., --cwd ../tree — era tomada tal como escrita e lida pelas regras de caminho erradas: no Windows respondia que um ficheiro de definições meio POSIX meio Windows não podia ser lido, e não encontrava relatório nenhum. Um separador final também já não faz parte da pasta.
• Uma opção que ninguém declarou não é um relatório. O summary -o out.json tomava -o por um relatório e dizia que esse ficheiro não existe. Só -h e -v são curtas; o -- continua a passar um ficheiro cujo nome começa por um traço, e uma opção escrita antes do comando é nomeada no erro em vez de receber toda a ajuda como resposta.
• O check --json diz o que diz o seu código de saída. Sem limiar definido escrevia "passed": false ao lado do código de saída 0, e um pipeline que lia o JSON em vez do código de saída fazia falhar uma execução que o comando tinha aprovado. passed é o código de saída numa palavra; configured é o que diz que não havia portão. Um --lines "" vazio é recusado em vez de desligar esse portão em silêncio.
• Uma comparação põe a linha de base onde põe a execução. O pathRemap e a raiz que um relatório declara eram aplicados à execução e não à linha de base, por isso uma linha de base escrita num servidor de compilação não emparelhava com nada e a comparação dizia que nada se tinha movido ao lado de um total que claramente se tinha movido.

Corrigido

• Os caminhos relativos de um relatório são ancorados onde esse relatório foi escrito. O llvm-cov escreve o caminho completo de um ficheiro; o gcovr escreve-o relativo à pasta de compilação onde está o seu relatório. Com ambos os relatórios de uma árvore, o summary listava duas vezes cada ficheiro que os dois tinham em comum — uma vez com os números de cada motor — e somava ambos ao total, porque um caminho relativo não tinha raiz contra a qual resolver e resolvia contra a pasta onde a shell estava naquele momento. Uma árvore de 5258 linhas era comunicada como 5836, e o excedente pertencia a ficheiros sob um caminho que não contém nenhum. Agora cada relatório é ancorado à sua própria pasta e às de cima, até à pasta onde o comando corre, como ambas as edições já fazem — assim os dois encontram-se como um único conjunto de ficheiros, sem uma regra pathRemap por diretório de compilação.
• Um ficheiro de definições que começa com uma marca de ordem de bytes também era recusado. Um editor no Windows pode escrevê-la à frente do texto; já não é tomada por parte do JSON.
• A saída encaminhada para um leitor que para cedo termina em silêncio. O summary encaminhado para o head, ou para o Select-Object -First do PowerShell, morria com um EPIPE não tratado e um stack trace. O leitor fechar o canal é uma escolha sua, não uma falha do comando: agora termina com o código de saída que tinha alcançado.

Corrigido

• Um ficheiro de definições com padrões era recusado. Com **/*.lcov.info num caminho de fuciniCoverage.coverageFile.paths e **/coverage.json no seguinte, todos os comandos terminavam com is not JSON: o que ficava entre os dois era tomado por um comentário. O ficheiro é agora lido como os editores o leem, incluindo um comentário depois de um valor e uma vírgula antes de um parêntese de fecho.

Adicionado

• O leitor na linha de comandos, grátis. npm install -g fucini-coverage — o mesmo leitor das duas edições, para os sítios onde não há editor. Um pacote, um comportamento no Windows, Linux, WSL e macOS, Node 20 ou mais recente.
• check, o gate. Código de saída 1 abaixo de um limiar em linhas, ramos, funções, MC/DC, condições, regiões, mutação ou a pontuação ponderada, a partir das definições ou da linha de comandos; --new-code 80 --base-ref origin/main julga as linhas que um ramo alterou, a partir de um git diff corrido pela ferramenta; --require-reasons faz falhar um marcador de exclusão sem motivo.
• summary, export, report, badge, compare. Os totais e cada ficheiro; a execução como CSV por ficheiro ou por função, Markdown, LCOV, Cobertura, SARIF, a lista de exclusões, um distintivo ou o JSON da Fucini; o relatório HTML de várias páginas; o distintivo colorido pela escala das definições; esta execução em relação a uma baseline, as regressões primeiro, com --fail-on-regression para uma verificação de pull request.
• mcp, para um agente de IA. As seis ferramentas das edições, servidas sobre a execução em 127.0.0.1 atrás de um token, com a entrada para o mcp.json do cliente impressa.
• O ficheiro de definições da edição para Visual Studio. fucini-coverage.json ao lado do código, com as chaves fuciniCoverage.* das definições do VS Code; .vscode/settings.json abaixo dele. Os relatórios são nomeados como ficheiros, pastas ou padrões, um .gz é descomprimido, e cada comando documenta-se a si próprio: fucini-coverage help <command>.

Alterado

• A avaliação de uma nova instalação começa com a primeira resposta do servidor de licenças. Até a extensão ter contactado fucini.software uma vez, funciona no nível Community e diz porquê. Uma instalação que já está em avaliação, ou que tem licença, não nota nada.
• Sem avaliação num contentor de desenvolvimento ou num Codespace. Aí a extensão arranca no nível Community; um código de subscrição, uma chave ou o passe de 7 dias desbloqueia tudo.
• O registo de utilização conhece uma máquina por um segundo hash, o do identificador próprio do sistema operativo. Só o hash é enviado; ver a política de privacidade.

Corrigido

• Pequenas correções. Uma versão de manutenção: pequenas correções internas, e nada que altere o que vê ou a forma de utilização.

Corrigido

• Pequenas correções. Uma versão de manutenção: pequenas correções internas, e nada que altere o que vê ou a forma de utilização.

Adicionado

• A cobertura no ecrã, para agentes de IA. Um agente que escrevesse testes podia executá-los e ler uma percentagem; não podia perguntar o que o Visual Studio sabe. Seis ferramentas respondem a isso, em palavras sobre as quais um agente pode agir: coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta e test_run_command. Um agente que fale MCP chega a elas através de um servidor que o Visual Studio executa quando fuciniCoverage.mcp.enabled está ativo — desligado por omissão, apenas em 127.0.0.1, atrás de um token só seu, e fechado a páginas web. Copy MCP Server Configuration põe a entrada do cliente na área de transferência.
• Os mesmos números que no ecrã. As ferramentas respondem a partir da execução que está carregada — as mesmas exclusões, o mesmo remapeamento — pelo que um agente a quem se pede que cubra as lacunas de uma função e um revisor a olhar para a margem estão a falar das mesmas linhas.

Alterado

• O plano de uma chave decide no Visual Studio o que decide no VS Code. Um plano que deixa de fora uma funcionalidade — MC/DC, o relatório HTML, os nomes dos testes que executaram uma linha — deixava-a de fora no VS Code e não aqui. Ambas as edições leem agora a mesma tabela: uma funcionalidade que o plano não inclui é retida, e o seu comando di-lo.
• A versão mínima que o servidor de licenças exige vale aqui também. Ambas as edições têm a mesma versão a partir da 2.2026.0, pelo que uma build mais antiga do que esse mínimo pede para ser atualizada, como faz a edição para VS Code.

Adicionado

• A cobertura no ecrã, para agentes de IA. Um agente que escrevesse testes podia executá-los e ler uma percentagem; não podia perguntar o que o editor sabe. Seis ferramentas respondem a isso, em palavras sobre as quais um agente pode agir: coverage_summary, coverage_gaps, tests_for_line, patch_coverage, coverage_delta e test_run_command. O agente do próprio VS Code tem-nas como ferramentas de modelo de linguagem, sem nada para configurar. Qualquer outro agente que fale MCP chega a elas através de um servidor que a extensão executa quando fuciniCoverage.mcp.enabled está ativo — desligado por omissão, apenas em 127.0.0.1, atrás de um token só seu, e fechado a páginas web. Copy MCP Server Configuration põe a entrada do cliente na área de transferência.
• Os mesmos números que no ecrã. As ferramentas respondem a partir da execução que está carregada — as mesmas exclusões, o mesmo remapeamento — pelo que um agente a quem se pede que cubra as lacunas de uma função e um revisor a olhar para a margem estão a falar das mesmas linhas.

Corrigido

• Um ficheiro medido por dois motores é um só ficheiro. O llvm-cov escreve o caminho completo de um ficheiro; o gcovr escreve-o relativo à pasta de compilação onde está o seu relatório. Um caminho relativo é ancorado na pasta do próprio relatório e nas pastas acima dela — mas, antes disso, o resolvedor perguntava se o caminho existia tal como estava, e essa pergunta é respondida a partir da pasta onde o próprio Visual Studio foi iniciado. Se essa pasta continha o ficheiro, o caminho continuava relativo: o ficheiro tinha dois nomes, aparecia duas vezes na janela Coverage e contava duas vezes nos totais. Uma árvore de 5258 linhas lia-se como 5836. Um caminho que não nomeia nenhuma localização sua já nem sequer é perguntado; é ancorado onde o relatório foi escrito, e a linha di-lo.

Corrigido

• Um ficheiro medido por dois motores é um só ficheiro. O llvm-cov escreve o caminho completo de um ficheiro; o gcovr escreve-o relativo à pasta de compilação onde está o seu relatório. Um caminho relativo é ancorado na pasta do próprio relatório e nas pastas acima dela — mas, antes disso, o resolvedor perguntava se o caminho existia tal como estava, e essa pergunta é respondida a partir da pasta onde o extension host foi iniciado, que depois de code . é a raiz do seu projeto. O caminho ficava então relativo: o ficheiro tinha dois nomes, aparecia duas vezes na vista Coverage e contava duas vezes nos totais. Uma árvore de 5258 linhas lia-se como 5836. Um caminho que não nomeia nenhuma localização sua já nem sequer é perguntado; é ancorado onde o relatório foi escrito, e a linha di-lo.
• O modo de margem que escolhe vale para a sessão, e as suas definições ficam como as escreveu. Escolher um modo na barra de estado, no seletor ou com Toggle Coverage Painting escrevia-o em settings.json — um ficheiro que em muitos projetos está sob controlo de versões e que era reescrito por um botão feito para ser premido duas vezes por minuto. A escolha vive agora durante a sessão, e um modo que tenha escrito nas suas definições continua a ganhar quando a janela abre.

Adicionado

• Run Mutation Tests Here. A cobertura diz que uma linha foi executada; uma ferramenta de mutação diz se um teste daria por ela estar errada. A função em que o cursor está — ou as linhas selecionadas, ou o ficheiro — é o que se manda o executor da pasta mutar, e o seu relatório é carregado ao lado da cobertura no ecrã: Stryker.NET para C#, StrykerJS para JavaScript e TypeScript, PIT com Maven para Java. A execução de mutação de um projeto leva uma hora; a de uma função leva um minuto.

Adicionado

• Run Mutation Tests Here. A cobertura diz que uma linha foi executada; uma ferramenta de mutação diz se um teste daria por ela estar errada. A função em que o cursor está — ou as linhas selecionadas, ou o ficheiro — é o que se manda o executor da pasta mutar, e o seu relatório é carregado ao lado da cobertura no ecrã: Stryker.NET para C#, StrykerJS para JavaScript e TypeScript, PIT com Maven para Java. A execução de mutação de um projeto leva uma hora; a de uma função leva um minuto.

Adicionado

• Run App with Coverage… mede aquilo a que uma pessoa chega, não só o que os testes fazem: a aplicação .NET da pasta é iniciada sob o dotnet-coverage da Microsoft, numa consola própria, e corre até ser fechada. O que foi percorrido é depois carregado como qualquer execução, e numa sessão de cobertura somado ao que os testes executaram. Requer dotnet tool install --global dotnet-coverage.

Adicionado

• Run App with Coverage… mede aquilo a que uma pessoa chega, não só o que os testes fazem: a aplicação .NET da pasta é iniciada sob o dotnet-coverage da Microsoft, numa consola própria, e corre até ser fechada. O que foi percorrido é depois carregado como qualquer execução, e numa sessão de cobertura somado ao que os testes executaram. Requer dotnet tool install --global dotnet-coverage.

Adicionado

• Uma referência de CI a partir de um artefacto zip. O GitHub e o GitLab publicam um artefacto como um arquivo. Onde baseline.report indica um — um URL, ou um zip no disco — ele é aberto e o relatório que contém é mantido: o membro indicado depois do # (ci/artifact.zip#coverage/lcov.info), senão o único ficheiro do arquivo, senão o seu único ficheiro que parece um relatório.

Adicionado

• Artefactos zip do GitHub e do GitLab. O CI publica um artefacto, e um artefacto é um arquivo. Um zip obtido é agora aberto e o relatório que contém é mantido — o membro indicado depois do # do URL (…/zip#coverage/lcov.info), senão o único ficheiro do arquivo, senão o seu único ficheiro que parece um relatório. Para um URL em coverageFile.paths, para baseline.report, e para uma referência que é um zip no disco.

Corrigido

• Os ficheiros de uma referência Cobertura não eram encontrados sob o <source> do próprio relatório. A comparação dizia 0 file(s) moved ao lado de um total que tinha mudado. A raiz que o relatório indica é agora usada, como acontece com um relatório que é carregado.

Adicionado

• Código novo por autor e por data. Código novo eram as linhas alteradas em relação a uma ref do git. Duas definições perguntam o que uma ref não pode: fuciniCoverage.gitDiff.author — as linhas que uma pessoa escreveu — e fuciniCoverage.gitDiff.since — as linhas escritas desde um dia. Ambas são lidas do git blame e aplicam-se à cobertura do diff e ao limiar do código novo.

Adicionado

• Código novo por autor e por data. Código novo eram as linhas alteradas em relação a uma ref do git. Duas definições perguntam o que uma ref não pode: fuciniCoverage.gitDiff.author — as linhas que uma pessoa escreveu — e fuciniCoverage.gitDiff.since — as linhas escritas desde um dia. Ambas são lidas do git blame e aplicam-se à cobertura do diff e ao limiar do código novo.

Adicionado

• Run This Test with Coverage lê Go e Rust. Num ficheiro Go, o func TestXxx do cursor é executado sozinho, no seu próprio pacote e pelo seu nome exato — go test ./pkg/calc -run "^TestTotal$". Num ficheiro Rust, a função #[test] é executada pelo seu caminho na crate, com --exact; num mod, os testes desse módulo; um teste de integração em tests/, no seu próprio binário.

Adicionado

• Run This Test with Coverage lê Go e Rust. Num ficheiro Go, o func TestXxx do cursor é executado sozinho, no seu próprio pacote e pelo seu nome exato — go test ./pkg/calc -run "^TestTotal$". Num ficheiro Rust, a função #[test] é executada pelo seu caminho na crate, com --exact; num mod, os testes desse módulo; um teste de integração em tests/, no seu próprio binário.

Adicionado

• A cobertura de condições do GCC 14, linha a linha. -fcondition-coverage era lido como duas contagens por ficheiro; cada condição é agora marcada na sua linha e nomeada na dica flutuante — condição 1 nunca verdadeira, condição 0 nunca num sentido nem no outro — a partir do JSON do gcov e da sua listagem em texto. threshold.conditions aplica-lhe um limiar, Copy Coverage Summary tem uma coluna Conditions, badge.metric aceita conditions, e a pesquisa aceita conditions < 80.

Corrigido

• O valor de ramos de uma função contava também os resultados das suas condições. branches 8/12 onde a ferramenta dizia 4 de 6. As condições ficam aí de fora, tal como nos valores do ficheiro e da execução.

Adicionado

• A cobertura de condições do GCC 14, linha a linha. -fcondition-coverage era lido como duas contagens por ficheiro; cada condição é agora marcada na sua linha e nomeada na dica flutuante — condição 1 nunca verdadeira, condição 0 nunca num sentido nem no outro — a partir do JSON do gcov e da sua listagem em texto. threshold.conditions aplica-lhe um limiar, Copy Coverage Summary tem uma coluna Conditions, badge.metric aceita conditions, e a pesquisa aceita conditions < 80.

Corrigido

• O valor de ramos de uma função contava também os resultados das suas condições. branches 8/12 onde a ferramenta dizia 4 de 6. As condições ficam aí de fora, tal como nos valores do ficheiro e da execução.

Adicionado

• A vista Coverage acompanha o editor. O ficheiro que está a ver é realçado na árvore, as pastas acima dele são abertas e a sua linha é deslocada para ficar visível. fuciniCoverage.coverageView.followActiveEditor desliga-o.

Adicionado

• A vista Coverage acompanha o editor. O ficheiro que está a ver é realçado na árvore, as pastas acima dele são abertas e a sua linha é deslocada para ficar visível. fuciniCoverage.coverageView.followActiveEditor desliga-o.

Adicionado

• Marcadores de exclusão só de ramos e do gcovr. LCOV_EXCL_BR_LINE e LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP retiram da contagem os ramos das suas linhas e deixam lá as linhas; LCOV_EXCL_EXCEPTION_BR_LINE retira apenas os ramos a que uma exceção chega. Todos os marcadores são lidos também sob os prefixos do gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE e os restantes.

Corrigido

• Um relatório .NET não mostrava cobertura de ramos. O Coverlet e o dotnet-coverage escrevem o atributo branch de uma linha Cobertura como True, e só o true em minúsculas era lido — pelo que todas as decisões de um relatório assim eram descartadas. Ambas as grafias são agora lidas. Os números mudam: a cobertura de ramos de um projeto .NET aparece onde não havia nenhuma, e a sua pontuação com ela.
• Um relatório Cobertura fundido a partir de várias árvores só encontrava os ficheiros da primeira árvore. Um relatório assim indica um <source> por árvore; cada um é agora tentado, pela ordem do relatório.

Adicionado

• Marcadores de exclusão só de ramos e do gcovr. LCOV_EXCL_BR_LINE e LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP retiram da contagem os ramos das suas linhas e deixam lá as linhas; LCOV_EXCL_EXCEPTION_BR_LINE retira apenas os ramos a que uma exceção chega. Todos os marcadores são lidos também sob os prefixos do gcovr: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOV_EXCL_BR_LINE e os restantes.

Corrigido

• Um relatório .NET não mostrava cobertura de ramos. O Coverlet e o dotnet-coverage escrevem o atributo branch de uma linha Cobertura como True, e só o true em minúsculas era lido — pelo que todas as decisões de um relatório assim eram descartadas. Ambas as grafias são agora lidas. Os números mudam: a cobertura de ramos de um projeto .NET aparece onde não havia nenhuma, e a sua pontuação com ela.
• Um relatório Cobertura fundido a partir de várias árvores só encontrava os ficheiros da primeira árvore. Um relatório assim indica um <source> por árvore; cada um é agora tentado, pela ordem do relatório.

Adicionado

• Show Minimal Test Set… encontra o menor número de testes que ainda executa todas as linhas que o conjunto de testes executa, e lista por baixo deles os testes que não acrescentam nenhuma linha própria. Para a execução rápida antes de um commit, e para quem poda o conjunto de testes — com o lembrete de que redundante em linhas não é redundante naquilo que um teste verifica.

Adicionado

• Show Minimal Test Set… encontra o menor número de testes que ainda executa todas as linhas que o conjunto de testes executa, e lista por baixo deles os testes que não acrescentam nenhuma linha própria. Para a execução rápida antes de um commit, e para quem poda o conjunto de testes — com o lembrete de que redundante em linhas não é redundante naquilo que um teste verifica.

Adicionado

• Exclusões justificadas. O código retirado da contagem no sítio onde está escrito pode dizer porquê — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — e os motivos são reportados: Export Coverage Report… lista as exclusões e as suas justificações em Markdown e em CSV. Com fuciniCoverage.exclusions.requireReason, uma exclusão que não dá motivo é um aviso na sua linha e faz falhar Check Coverage Thresholds.

Adicionado

• Exclusões justificadas. O código retirado da contagem no sítio onde está escrito pode dizer porquê — // LCOV_EXCL_LINE: defensive, unreachable by construction, [ExcludeFromCodeCoverage(Justification = "…")] — e os motivos são reportados: Export Coverage Report… lista as exclusões e as suas justificações em Markdown e em CSV. Com fuciniCoverage.exclusions.requireReason, uma exclusão que não dá motivo é um aviso na sua linha e faz falhar Check Coverage Thresholds.

Adicionado

• Um limiar para o código novo, ao lado dos limiares da execução inteira. fuciniCoverage.threshold.newCode é a cobertura de linhas mínima, em percentagem, das linhas alteradas em relação a gitDiff.baseRef. Check Coverage Thresholds dá-o como falhado numa frase própria — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — e a execução inteira continua no ecrã.
• Show Indirect Coverage Changes… lista as linhas cuja cobertura mudou sem que ninguém as editasse — código que deixou de ser executado porque um teste desapareceu, ou porque um ramo a montante agora retorna mais cedo. Em relação à referência de CI onde baseline.report indica uma, senão em relação à execução anterior.

Adicionado

• Um limiar para o código novo, ao lado dos limiares da execução inteira. fuciniCoverage.threshold.newCode é a cobertura de linhas mínima, em percentagem, das linhas alteradas em relação a gitDiff.baseRef. Check Coverage Thresholds dá-o como falhado numa frase própria — New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran) — e a execução inteira continua no ecrã.
• Show Indirect Coverage Changes… lista as linhas cuja cobertura mudou sem que ninguém as editasse — código que deixou de ser executado porque um teste desapareceu, ou porque um ramo a montante agora retorna mais cedo. Em relação à referência de CI onde baseline.report indica uma, senão em relação à execução anterior.

Adicionado

• Run Tests Affected by My Changes… lista os testes que executaram uma linha que a árvore de trabalho altera em relação a fuciniCoverage.testImpact.baseRef (HEAD por omissão), com o que executou a maior parte da alteração em primeiro lugar. Escolher um teste abre-o; onde os relatórios vieram de uma execução por teste (testRun.perTest), a primeira entrada executa só esses testes.

Corrigido

• testRun.skipWhenTestsFail mantém-se para lá da execução. Os relatórios que uma execução vermelha escrevia ficavam no disco, onde o observador os carregava um momento depois. Agora são removidos.
• A cópia que um logger TRX faz de um relatório de cobertura nunca é tomada por um tracefile.

Adicionado

• Run Tests Affected by My Changes… lista os testes que executaram uma linha que a árvore de trabalho altera em relação a fuciniCoverage.testImpact.baseRef (HEAD por omissão), com o que executou a maior parte da alteração em primeiro lugar. Escolher um teste abre-o; onde os relatórios vieram de uma execução por teste (testRun.perTest), a primeira entrada executa só esses testes.

Corrigido

• testRun.skipWhenTestsFail mantém-se para lá da execução. Os relatórios que uma execução vermelha escrevia ficavam no disco, onde o observador os carregava um momento depois. Agora são removidos.
• A cópia que um logger TRX faz de um relatório de cobertura nunca é tomada por um tracefile.

Adicionado

• Passou ou falhou, nas marcas. Uma linha que um teste falhado executou recebe uma barra vermelha no início, e a sua dica flutuante nomeia os testes falhados; Show Tests That Ran This Line diz quais dos testes falharam. É preciso um relatório que diga que testes executaram uma linha, e o ficheiro de resultados do executor de testes — TRX ou JUnit XML — na pasta do relatório ou indicado em fuciniCoverage.testResults.paths. Run Tests with Coverage pede agora um ao dotnet test.
• A cobertura de código do próprio Visual Studio, carregada. O ficheiro .coverage que o Analyze Code Coverage do Visual Studio escreve é convertido com dotnet-coverage e carrega-se por si: o Coverage Studio assenta no coletor incorporado em vez de competir com ele.

Adicionado

• Passou ou falhou, nas marcas. Uma linha que um teste falhado executou recebe uma barra vermelha no início, e a sua dica flutuante nomeia os testes falhados; Show Tests That Ran This Line diz quais dos testes falharam. É preciso um relatório que diga que testes executaram uma linha, e o ficheiro de resultados do executor de testes — TRX ou JUnit XML — na pasta do relatório ou indicado em fuciniCoverage.testResults.paths. Run Tests with Coverage pede agora um ao dotnet test.

Corrigido

• A caixa de pesquisa mantém a consulta, e o foco, quando a cobertura é recarregada. Cada recarregamento esvaziava-a, muitas vezes enquanto a consulta ainda estava a ser escrita. Uma consulta como < 80% mantém também os pontos quentes de risco a que corresponde.
• Uma sessão de cobertura já não conta a mesma execução duas vezes. Cada recarregamento de relatórios inalterados voltava a somá-los, e todas as contagens de execuções duplicavam. Uma sessão guarda agora cada conjunto de relatórios uma só vez.
• A referência de CI já não atrasa um carregamento. O carregamento é desenhado primeiro e a comparação vem depois. A referência é preparada uma vez e mantida enquanto o seu relatório e as definições não mudarem, e quando o URL não pode ser alcançado usa-se a cópia obtida anteriormente.
• «Desde a última execução» sobrevive a um recarregamento de relatórios inalterados. Uma alteração de definições ou uma atualização fazia da execução no ecrã a sua própria última execução, e todas as alterações desde a execução anterior desapareciam. Uma releitura destas também já não é guardada no histórico.
• Um carregamento de cada vez. Dois recarregamentos pedidos ao mesmo tempo corriam lado a lado, e ganhava o mais lento. Os recarregamentos pedidos durante um carregamento passam agora a ser um só carregamento depois dele.
• Uma referência de CI por HTTP é obtida como no VS Code. Um só cliente, a última cópia guardada para quando o servidor não pode ser alcançado, e remote.headers enviados apenas para o endereço para o qual foram escritos — nunca por HTTP simples.
• Um comando cujo trabalho falha di-lo. Uma falha num comando ou num temporizador era engolida; é agora uma linha na janela de Saída.
• Menos trabalho na thread da interface. Os observadores de ficheiros são criados em segundo plano, as entradas da Lista de Erros são calculadas uma vez por carregamento, e o registo é escrito em blocos em vez de linha a linha.
• Duas janelas do Visual Studio já não danificam o histórico de execuções. O seu índice é substituído num só passo sob um bloqueio que ambas partilham, e refeito a partir das execuções quando se perde.
• Run Native Project with Coverage compila a plataforma do próprio projeto, e vai buscar llvm-cov e llvm-profdata ao LLVM do compilador, como um par.
• As cores de aviso, de erro e de aprovado da janela Coverage acompanham um tema claro tal como um escuro.
• Um ficheiro de definições aberto com alterações por gravar não é sobrescrito. A página de definições diz para o gravar primeiro.

Alterado

• Um ficheiro de cobertura que escolhe, e o relatório que uma execução de testes escreve, são memorizados por si em vez de serem escritos em .vscode/settings.json. Esse ficheiro é muitas vezes incluído nos commits, pelo que uma execução de testes deixava no repositório uma alteração que ninguém tinha pedido. Os caminhos que já estão em coverageFile.paths continuam a funcionar.

Corrigido

• A caixa de pesquisa mantém a consulta, e o foco, quando a cobertura é recarregada. Cada recarregamento esvaziava-a, muitas vezes enquanto a consulta ainda estava a ser escrita. Uma consulta como < 80% mantém também os pontos quentes de risco a que corresponde.
• Uma sessão de cobertura já não conta a mesma execução duas vezes. Cada recarregamento de relatórios inalterados voltava a somá-los, e todas as contagens de execuções duplicavam. Uma sessão guarda agora cada conjunto de relatórios uma só vez.
• A referência de CI já não atrasa um carregamento. O carregamento é desenhado primeiro e a comparação vem depois. A referência é preparada uma vez e mantida enquanto o seu relatório e as definições não mudarem, e quando o URL não pode ser alcançado usa-se a cópia obtida anteriormente.
• A verificação de ficheiros de relatório alterados faz uma passagem de cada vez. Numa unidade de rede lenta, duas passagens viam a mesma alteração, e a cobertura era carregada duas vezes.
• «Desde a última execução» sobrevive a um recarregamento de relatórios inalterados. Uma alteração de definições ou uma atualização fazia da execução no ecrã a sua própria última execução, e todas as alterações desde a execução anterior desapareciam. Uma releitura destas também já não é guardada no histórico.

Alterado

• Um ficheiro de cobertura que escolhe, e o relatório que uma execução de testes escreve, são memorizados por si em vez de serem escritos em .vscode/settings.json. Esse ficheiro é muitas vezes incluído nos commits, pelo que uma execução de testes deixava no repositório uma alteração que ninguém tinha pedido. Os caminhos que já estão em coverageFile.paths continuam a funcionar.

Corrigido

• Uma solução .NET com dois ou mais projetos de teste já não perde a cobertura de todos os projetos menos um. O dotnet test escrevia um relatório por projeto e todos eram movidos para o mesmo coverage/coverage.cobertura.xml, pelo que só o último era carregado. Uma pasta assim executa agora o dotnet test uma vez por projeto de teste, cada relatório vai para coverage/<Project>/, e a execução de um projeto substitui apenas o relatório desse projeto.
• Gravar vários ficheiros de uma vez executa os testes de todos os ficheiros gravados. Com testRun.onSave só corriam os testes do último ficheiro; as gravações que chegam enquanto decorre uma execução são guardadas e executadas em conjunto depois dela.
• Run This Test with Coverage e as execuções por teste executam exatamente o que nomeiam. O filtro .NET correspondia por subcadeia: Total executava também TotalTax. Um teste é agora executado pelo seu nome exato, uma classe pelo seu nome seguido de um ponto, e um teste numa classe aninhada é encontrado (Outer+Inner).
• Um teste jest ou vitest cujo título contém (, + ou $ é executado. O título ia para -t, que lê uma expressão regular, pelo que um teste assim não correspondia a nada e nada era executado.
• Run This Test with Coverage lê ficheiros de teste VB e F#. <Fact> acima de Public Sub, e [<Fact>] acima de let ou member, nunca eram reconhecidos.
• Cancelar uma execução de testes termina todos os processos que ela iniciou. Só a shell era terminada, e o dotnet test continuava a correr por trás dela. Fechar o Visual Studio também cancela a execução.
• Escrever durante uma execução após uma gravação já não desloca as marcas. Ficam presas ao texto que a execução mediu.
• Uma solução numa partilha de rede executa aí os seus testes. A execução começava em C:\Windows, porque a shell de comandos não aceita um caminho \\server\share como a sua pasta.

Corrigido

• Uma solução .NET com dois ou mais projetos de teste já não perde a cobertura de todos os projetos menos um. O dotnet test escrevia um relatório por projeto e todos eram movidos para o mesmo coverage/coverage.cobertura.xml, pelo que só o último era carregado. Uma pasta assim executa agora o dotnet test uma vez por projeto de teste, cada relatório vai para coverage/<Project>/, e a execução de um projeto substitui apenas o relatório desse projeto.
• Gravar vários ficheiros de uma vez executa os testes de todos os ficheiros gravados. Com testRun.onSave só corriam os testes do último ficheiro; as gravações que chegam enquanto decorre uma execução são guardadas e executadas em conjunto depois dela.
• Run This Test with Coverage e as execuções por teste executam exatamente o que nomeiam. O filtro .NET correspondia por subcadeia: Total executava também TotalTax. Um teste é agora executado pelo seu nome exato, uma classe pelo seu nome seguido de um ponto, e um teste numa classe aninhada é encontrado (Outer+Inner).
• Um teste jest ou vitest cujo título contém (, + ou $ é executado. O título ia para -t, que lê uma expressão regular, pelo que um teste assim não correspondia a nada e nada era executado.
• Um título de teste com aspas chega inteiro ao terminal. Um comando com \" dentro de aspas desfazia-se na primeira.
• Run This Test with Coverage lê ficheiros de teste VB e F#. <Fact> acima de Public Sub, e [<Fact>] acima de let ou member, nunca eram reconhecidos.
• Uma tarefa de teste que termina sem iniciar um processo já não deixa Run Tests with Coverage à espera para sempre. Termina, e diz que a execução não escreveu nada.

Adicionado

• Que testes executaram esta linha. Onde o relatório o regista — coverage.py com --show-contexts, os métodos rastreados do OpenCover, um tracefile lcov escrito por teste — o CodeLens de uma função diz quantos testes a executaram, e Show Tests That Ran This Line lista-os, os mais ativos primeiro, e abre o que escolher. Para uma execução dotnet test, testRun.perTest executa os testes uma classe de cada vez, para que cada relatório diga que classe o escreveu.
• Cobertura após cada gravação. Com testRun.onSave, gravar um ficheiro fonte executa os testes que o cobrem, com cobertura, e a margem acompanha. Numa solução .NET só correm os projetos de teste que referenciam o projeto do ficheiro gravado; várias gravações seguidas são uma só execução.
• Run This Test with Coverage. Com o cursor num método de teste, numa classe de teste ou num describe, ou num ficheiro de teste, um só comando executa exatamente isso com cobertura — dotnet test --filter, jest/vitest -t ou um node id do pytest — e carrega o que escreveu. O teste é lido do texto, por isso funciona para C#, VB, F#, JavaScript, TypeScript e Python sem serviço de linguagem.
• Exclude from Coverage, e dois filtros .NET. Um clique direito numa linha da árvore de cobertura, ou Exclude This File from Coverage no ficheiro aberto, acrescenta o ficheiro ou a pasta a fuciniCoverage.ignore, e ele sai de todos os totais. ignore.namespaces deixa de fora os ficheiros de um namespace (*.Migrations), e ignore.attributes a classe, o método ou a propriedade sob um atributo — ExcludeFromCodeCoverage por omissão, que o OpenCover, o dotCover e um lcov convertido não respeitam.
• Exclude Selection from Coverage. Selecione linhas e escolha a ação na lâmpada ou no menu de contexto do editor: acima de uma classe, método ou propriedade .NET escreve [ExcludeFromCodeCoverage] — na forma curta quando o ficheiro já importa System.Diagnostics.CodeAnalysis — e noutros casos LCOV_EXCL_LINE ou um par LCOV_EXCL_START/STOP no comentário próprio da linguagem. Um marcador que já lá está não é duplicado.
• Namespaces, classes e métodos. Para um relatório .NET que nomeia as suas classes — Cobertura, Coverlet, OpenCover — uma lista Folders / Namespaces mostra a mesma execução por namespace, classe e método, com a mesma ordenação e o mesmo filtro; uma linha de método abre o ficheiro no método. Os tipos gerados pelo compilador, como <>c e as máquinas de estados async, são incorporados na classe para a qual foram gerados.
• Uma caixa de pesquisa sobre a árvore de cobertura. Escreva palavras para manter as linhas cujo nome ou caminho as contém todas, ou uma comparação — < 80%, lines >= 90, branches = 0 — para manter as linhas cujo valor a cumpre; as duas juntas exigem as duas. As linhas de métodos e os pontos quentes de risco também são pesquisados; Escape limpa.
• Run Native Project with Coverage. O projeto de arranque C++, a partir do menu Tools: um projeto ClangCL é compilado de novo com a instrumentação de cobertura do clang em coverage/native/, executado, e o seu relatório carregado; qualquer outro conjunto de ferramentas corre sob o OpenCppCoverage onde estiver instalado, e onde nenhuma das duas coisas é possível uma frase diz o que instalar.
• Sessões de cobertura e uma tendência. Start Coverage Session, e cada execução carregada a partir daí soma-se às anteriores — linhas, ramos e funções por igual: o que qualquer uma delas executou está coberto — para que os testes unitários, os de integração e uma volta pela aplicação mostrem o que alcançaram juntos. Por baixo da barra de ferramentas, a cobertura de linhas do histórico guardado é desenhada como tendência, um ponto por execução.
• Compare Two History Runs, como no VS Code: escolha duas execuções guardadas e os ficheiros que mudaram entre elas são listados da mais antiga para a mais recente, seja qual for a escolhida primeiro.
• Compare with CI Baseline. baseline.report indica o relatório que a build do seu ramo principal publica — um URL, obtido com remote.headers, ou um ficheiro descarregado — e cada carregamento é medido em relação a ele: o cartão da barra de estado diz onde está esta execução, e Compare with CI Baseline lista os ficheiros que mudaram. A referência passa pela mesma lista de exclusões que a execução, para que os totais se comparem em pé de igualdade.
• Onde os encontrar. Os novos comandos estão em Tools > Coverage Studio e no menu de contexto do editor; Show Tests That Ran This Line é também Ctrl+Shift+U, T, e Exclude Selection from Coverage é uma ação da lâmpada.

Corrigido

• O relatório de uma execução de testes já não leva o seu nome de utilizador e de máquina. O coletor Code Coverage da Microsoft chama ao seu relatório <user>_<machine>_<stamp>.cobertura.xml, e esse nome aparecia na árvore e em cada captura de ecrã dela; o relatório é agora renomeado para coverage.cobertura.xml antes de ser carregado.
• Dizia-se de um ficheiro gerado que era deixado de fora por fuciniCoverage.ignore. Cada ficheiro excluído é agora contado sob a definição que o excluiu — ignore, ignore.generated ou ignore.namespaces — pelo que o nome mostrado é o que deve mudar.
• Um tracefile lcov escrito por teste é lido como um registo por ficheiro, com as secções de teste somadas, como o VS Code o lê; antes, o registo de cada teste era um ficheiro à parte.
• O registo diz o que um parser deixou de fora. Os ficheiros em que um parser não encontrou nada para instrumentar (FUCINI_PARSE_030) e o relato que um relatório faz das suas próprias lacunas (FUCINI_PARSE_031, o MissingPdb do OpenCover) são escritos no registo, como o VS Code os escreve.
• Um cabeçalho de macros já não aparece na árvore a 100%. O llvm-cov e o gcov atribuem os usos de uma macro às linhas que a definem; os ramos e funções em linhas excluídas vão-se agora com as linhas, e um ficheiro sem nada mensurável é retirado da execução e nomeado na saída (FUCINI_EXCLUDE_001).
• Cinco relatórios recusados como formato não suportado são reconhecidos. O JaCoCo XML do Kover, um relatório Stryker.NET, um relatório NCover, um resultset antigo do SimpleCov e um relatório SonarQube de muitos ficheiros vazios são agora reconhecidos pelo que trazem no início. Um relatório Clover ou SonarQube cujos caminhos contêm a palavra cobertura já não é lido como Cobertura.
• Números que coincidem com as ferramentas que os escreveram. O valor de ramos de uma build MC/DC coincide com llvm-cov report; os ramos de exceção do LCOV 2 (BRDA:12,e0,1,3) contam; uma função do llvm-cov só é declarada no ficheiro que a define; um bloco Go listado por dois binários de teste soma as suas contagens; uma decisão Cobertura reportada por duas classes e uma linha JaCoCo listada duas vezes mantêm todos os seus ramos, uma vez.
• Outras menores. Um tracefile cortado a meio da escrita já não perde um ficheiro; gcov -t sobre vários ficheiros .gcda dá um ficheiro para cada um, as instanciações de templates são lidas uma vez e contagens como 1.20k do gcov -H são mantidas; os ficheiros GNATcoverage já não são todos dados como alterados desde a sua cobertura; um mutante Stryker pendente ou uma execução PIT interrompida já não contam contra a pontuação.
• Uma edição à mão do ficheiro de definições é aplicada ao ser gravada, como o VS Code aplica uma alteração de definições.

Adicionado

• Que testes executaram esta linha. Onde o relatório o regista — coverage.py com --show-contexts, os métodos rastreados do OpenCover, um tracefile lcov escrito por teste — o CodeLens de uma função diz quantos testes a executaram, e Show Tests That Ran This Line lista-os, os mais ativos primeiro, e abre o que escolher. Para uma execução dotnet test, testRun.perTest executa os testes uma classe de cada vez, para que cada relatório diga que classe o escreveu.
• Cobertura após cada gravação. Com testRun.onSave, gravar um ficheiro fonte executa os testes que o cobrem, com cobertura, e a margem acompanha. Numa solução .NET só correm os projetos de teste que referenciam o projeto do ficheiro gravado; várias gravações seguidas são uma só execução.
• Run This Test with Coverage. Com o cursor num método de teste, numa classe de teste ou num describe, ou num ficheiro de teste, um só comando executa exatamente isso com cobertura — dotnet test --filter, jest/vitest -t ou um node id do pytest — e carrega o que escreveu. O teste é lido do texto, por isso funciona para C#, VB, F#, JavaScript, TypeScript e Python sem serviço de linguagem.
• Exclude from Coverage, e dois filtros .NET. Um clique direito numa linha da árvore de cobertura, ou Exclude This File from Coverage no ficheiro aberto, acrescenta o ficheiro ou a pasta a fuciniCoverage.ignore, e ele sai de todos os totais. ignore.namespaces deixa de fora os ficheiros de um namespace (*.Migrations), e ignore.attributes a classe, o método ou a propriedade sob um atributo — ExcludeFromCodeCoverage por omissão, que o OpenCover, o dotCover e um lcov convertido não respeitam.
• Exclude Selection from Coverage. Selecione linhas e escolha a ação na lâmpada ou no menu de contexto do editor: acima de uma classe, método ou propriedade .NET escreve [ExcludeFromCodeCoverage] — na forma curta quando o ficheiro já importa System.Diagnostics.CodeAnalysis — e noutros casos LCOV_EXCL_LINE ou um par LCOV_EXCL_START/STOP no comentário próprio da linguagem. Um marcador que já lá está não é duplicado.
• Namespaces, classes e métodos. Para um relatório .NET que nomeia as suas classes — Cobertura, Coverlet, OpenCover — uma lista Folders / Namespaces mostra a mesma execução por namespace, classe e método, com a mesma ordenação e o mesmo filtro; uma linha de método abre o ficheiro no método. Os tipos gerados pelo compilador, como <>c e as máquinas de estados async, são incorporados na classe para a qual foram gerados.
• Uma caixa de pesquisa sobre a árvore de cobertura. Escreva palavras para manter as linhas cujo nome ou caminho as contém todas, ou uma comparação — < 80%, lines >= 90, branches = 0 — para manter as linhas cujo valor a cumpre; as duas juntas exigem as duas. As linhas de métodos e os pontos quentes de risco também são pesquisados; Escape limpa.
• Sessões de cobertura e uma tendência. Start Coverage Session, e cada execução carregada a partir daí soma-se às anteriores — linhas, ramos e funções por igual: o que qualquer uma delas executou está coberto — para que os testes unitários, os de integração e uma volta pela aplicação mostrem o que alcançaram juntos. Por baixo da barra de ferramentas, a cobertura de linhas do histórico guardado é desenhada como tendência, um ponto por execução.
• Compare with CI Baseline. baseline.report indica o relatório que a build do seu ramo principal publica — um URL, obtido com remote.headers, ou um ficheiro descarregado — e cada carregamento é medido em relação a ele: o cartão da barra de estado diz onde está esta execução, e Compare with CI Baseline lista os ficheiros que mudaram. A referência passa pela mesma lista de exclusões que a execução, para que os totais se comparem em pé de igualdade.

Corrigido

• O relatório de uma execução de testes já não leva o seu nome de utilizador e de máquina. O coletor Code Coverage da Microsoft chama ao seu relatório <user>_<machine>_<stamp>.cobertura.xml, e esse nome aparecia na árvore e em cada captura de ecrã dela; o relatório é agora renomeado para coverage.cobertura.xml antes de ser carregado.
• Uma execução de testes falhava no Windows quando o terminal é PowerShell. As aspas à volta de Code Coverage;Format=cobertura perdiam-se a caminho do pwsh, que lia o ; como fim do comando; a receita é agora entregue ao terminal palavra a palavra e citada para a shell que ele arranca.
• Dizia-se de um ficheiro gerado que era deixado de fora por fuciniCoverage.ignore. Cada ficheiro excluído é agora contado sob a definição que o excluiu — ignore, ignore.generated ou ignore.namespaces — pelo que o nome mostrado é o que deve mudar.
• Um cabeçalho de macros já não aparece na árvore a 100%. O llvm-cov e o gcov atribuem os usos de uma macro às linhas que a definem; os ramos e funções em linhas excluídas vão-se agora com as linhas, e um ficheiro sem nada mensurável é retirado da execução e nomeado na saída (FUCINI_EXCLUDE_001).
• Cinco relatórios recusados como formato não suportado são reconhecidos. O JaCoCo XML do Kover, um relatório Stryker.NET, um relatório NCover, um resultset antigo do SimpleCov e um relatório SonarQube de muitos ficheiros vazios são agora reconhecidos pelo que trazem no início. Um relatório Clover ou SonarQube cujos caminhos contêm a palavra cobertura já não é lido como Cobertura.
• Números que coincidem com as ferramentas que os escreveram. O valor de ramos de uma build MC/DC coincide com llvm-cov report; os ramos de exceção do LCOV 2 (BRDA:12,e0,1,3) contam; uma função do llvm-cov só é declarada no ficheiro que a define; um bloco Go listado por dois binários de teste soma as suas contagens; uma decisão Cobertura reportada por duas classes e uma linha JaCoCo listada duas vezes mantêm todos os seus ramos, uma vez.
• Outras menores. Um tracefile cortado a meio da escrita já não perde um ficheiro; gcov -t sobre vários ficheiros .gcda dá um ficheiro para cada um, as instanciações de templates são lidas uma vez e contagens como 1.20k do gcov -H são mantidas; os ficheiros GNATcoverage já não são todos dados como alterados desde a sua cobertura; um mutante Stryker pendente ou uma execução PIT interrompida já não contam contra a pontuação.

Alterado

• Acabou o FUCINI_ENCODING_001 a cada carregamento. Um relatório sem marca de ordem de bytes é lido como UTF-8, como qualquer ferramenta o escreve, sem uma nota a dizê-lo.

Adicionado

• Uma entrada relativa com um wildcard é pesquisada a qualquer profundidade. *.lcov.info em coverageFile.paths encontra o ficheiro onde quer que esteja sob a pasta base, tal como o VS Code sempre leu uma entrada destas; uma entrada absoluta — ${workspaceFolder}/build/coverage-merged/*.lcov.info, ** para qualquer profundidade — procura exatamente onde diz, como antes.
• Observado onde o relatório vai aparecer. A observação cobre as pastas que as definições nomeiam, esteja ou não já lá um relatório: a pasta de um ficheiro absoluto, as pastas antes de um wildcard — com tudo o que está abaixo delas quando o padrão desce às subpastas — e a pasta base para um wildcard relativo. Um relatório que uma compilação aí escreva carrega-se por si; uma escrita em qualquer outro ficheiro dessas pastas é ignorada.

Corrigido

• Um relatório JSON do llvm-cov era recusado como formato não suportado. O formato é reconhecido pelos primeiros 4096 caracteres, e o llvm-cov escreve o seu marcador "type": "llvm.coverage.json.export" mesmo no fim; uma exportação cujo primeiro registo de ficheiro traz muitos ramos e expansões de macros aninhadas não tinha mais nada reconhecível nesse início. Um relatório assim é agora reconhecido pela sua abertura, {"data":[{"files":[, que nenhum outro formato tem.
• O mesmo para gcov --json-format. O gcov escreve as funções de um ficheiro antes das suas linhas, e um ficheiro com uma dúzia de funções também não tem nenhuma entrada de linha no início inspecionado; a chave gcc_version do próprio documento identifica-o agora.

Adicionado

• Um wildcard numa entrada absoluta de coverageFile.paths. ${workspaceFolder}/build/coverage-merged/*.lcov.info carrega todos os ficheiros assim nessa pasta, e ** vale por qualquer profundidade: as pastas antes do primeiro wildcard são pesquisadas, o resto é o padrão abaixo delas, tal como a edição para Visual Studio sempre leu uma entrada destas. Antes, uma entrada absoluta era procurada tal como estava escrita, pelo que uma com asterisco não correspondia a nada — e, sendo um wildcard, também nunca era reportada como não correspondendo a nada. Um relatório que aí apareça mais tarde é carregado pelo observador ou pela sondagem como uma entrada literal; um wildcard que não corresponde a nada não é reportado, porque pode estar à espera de uma compilação.

Corrigido

• Um relatório JSON do llvm-cov era recusado como formato não suportado. O formato é reconhecido pelos primeiros 4096 caracteres, e o llvm-cov escreve o seu marcador "type": "llvm.coverage.json.export" mesmo no fim; uma exportação cujo primeiro registo de ficheiro traz muitos ramos e expansões de macros aninhadas não tinha mais nada reconhecível nesse início. Um relatório assim é agora reconhecido pela sua abertura, {"data":[{"files":[, que nenhum outro formato tem.
• O mesmo para gcov --json-format. O gcov escreve as funções de um ficheiro antes das suas linhas, e um ficheiro com uma dúzia de funções também não tem nenhuma entrada de linha no início inspecionado; a chave gcc_version do próprio documento identifica-o agora.

Adicionado

• Escolher ou combinar os relatórios de um ficheiro. Clique com o botão direito num ficheiro na janela Coverage e escolha Choose Coverage Source... — oferecido onde mais do que um relatório carregado o mede — ou use Tools > Coverage Studio > Choose Coverage Source for This File...: cada relatório com os seus próprios números, depois Combine them — agree (coberta só onde todos os relatórios executaram uma linha: uma base de código, dois compiladores) e — union (coberta onde qualquer um o fez: vários conjuntos de testes de uma mesma build), para o ficheiro, a sua pasta ou um padrão. As linhas em que os relatórios divergem ficam a azul-petróleo na margem e no Annotated Source, com o que cada relatório disse; a linha do ficheiro indica os relatórios e o número de linhas em disputa, e a barra de estado e ambos os cartões dizem de onde vêm os números.
• Vermelho, âmbar e verde. Gutter: Coverage pinta de verde cada linha coberta ao lado do vermelho e do âmbar — o modo para quem esperava que um ficheiro a 100% fosse verde. Os cinco tons do mapa de calor são definições (heatmap.colors, heatmap.colorsDark), e a janela de definições pré-visualiza cada cor enquanto é escolhida.

Corrigido

• O número do ficheiro na barra de estado é o do seu cartão. Uma métrica vazia — MC/DC num ficheiro sem decisões — contava como 100% no item e não contava de todo no cartão que ele abre.
• Um cabeçalho de constantes já não indica 0% nem 100%. As diretivas do pré-processador contam como não-código, tal como os comentários, quando excludeComments está ativo.

Adicionado

• Escolher ou combinar os relatórios de um ficheiro. coverageFile.sources decide, ficheiro a ficheiro, qual de vários relatórios carregados fala por ele — ou combina-os: agree conta uma linha como coberta só onde todos os relatórios a executaram e marca a azul-petróleo as linhas em que divergem; union onde qualquer um o fez. Choose Coverage Source... numa linha da vista Coverage ou para o ficheiro aberto escreve a regra por si. Faz parte dos planos pagos; no Community decide o relatório mais recente.
• Vermelho, âmbar e verde, e um modo de margem a um clique. O modo coverage pinta de verde as linhas cobertas; os tons do mapa de calor são definições com pré-visualização em direto no painel de definições; um botão na barra de estado e Alt+G fazem a margem passar por desligado, não coberto, cobertura e mapa de calor.

Corrigido

• O número do ficheiro na barra de estado é o do seu cartão. Uma métrica vazia — MC/DC num ficheiro sem decisões — contava como 100% no item e não contava de todo no cartão que ele abre.
• Um cabeçalho de constantes já não indica 0% nem 100%. As diretivas do pré-processador contam como não-código, tal como os comentários, quando excludeComments está ativo.

Alterado

• A caixa de diálogo Licence pede apenas o código. Os quatro botões de plano desapareceram: um código de subscrição ou de convite designa um pool, e o pool conhece o seu plano, pelo que não havia nada que uma pessoa pudesse responder melhor do que o próprio código — e um convite Business colado com o Pro ainda selecionado era recusado por ser do plano errado. Cole o código e prima Activate.

Alterado

• Enter Subscription Code pede apenas o código. A pergunta sobre o plano desapareceu: o código designa um pool e o pool conhece o seu plano, pelo que o servidor trata do resto e já não recusa um código por ser do plano errado. As ligações de um clique nos e-mails mantêm-se; os e-mails de ativação já não têm o passo «escolha o seu plano», e o mesmo código ativa o Coverage Studio para Visual Studio sem precisar do VS Code.

Adicionado

• Cobertura após cada execução de testes. Collect Coverage in Test Explorer… coloca um .runsettings com o coletor Cobertura da Microsoft ao lado da solução — apanhado por si com Tools → Options → Test → Auto detect runsettings files ativo, ou selecionado uma vez em Test → Configure Run Settings; a partir daí cada execução do Test Explorer escreve um relatório sob o projeto de testes, e ele é carregado no momento em que aparece, fundido com o que quer que as definições nomeiem. Nada se liga ao Test Explorer, por isso o Visual Studio 2026 e o Microsoft.Testing.Platform funcionam tal como estão. Run Tests with Coverage reconhece dotnet test, vitest, jest, pytest, go, cargo, maven, gradle, phpunit e ctest, executa-os com a cobertura ativa na janela Output e carrega o que eles escreveram; um projeto de testes sem coverlet.collector é executado com o coletor que o SDK de testes inclui.
• Desde a última execução. Cada carregamento é comparado com o anterior: um triângulo na margem em cada linha que começou ou deixou de correr, a tendência ao lado da pontuação, e Compare with Last Run para os ficheiros cujos números mudaram. history.enabled guarda as execuções entre reinícios; gitDiff.enabled reduz a execução às linhas que o seu ramo alterou.
• Os gates e a Error List. Check Coverage Thresholds julga a execução contra threshold.*; com compliance.diagnostics, problems.enabled, problems.perLine ou deadCode.enabled as ocorrências ficam na Error List ao lado das do próprio compilador, cada uma abrindo o seu ficheiro.
• Relatórios, exportações e um distintivo. Show Annotated Source abre o ficheiro ativo como uma página na área de documentos — cada linha na sua cor, as ocorrências ao lado — deslocada com o editor em ambos os sentidos. Open HTML Report e Generate Full HTML Report escrevem a execução em htmlReport.outputDir e abrem o browser. Export Coverage Report… escreve CSV por ficheiro ou por função, Markdown, LCOV, Cobertura, SARIF, um distintivo SVG ou Fucini JSON. Generate Coverage Badge mantém o distintivo no repositório, após cada carregamento com badge.autoUpdate.
• Risk hotspots e filtros de linhas na janela Coverage, como no VS Code: as funções onde código complexo se encontra com pouca cobertura, da pior para a melhor; e uma lista pendente ao lado da ordenação para todos os ficheiros, os ficheiros com lacunas, os ficheiros não testados, ou os ficheiros alterados desde a última execução.
• Um ficheiro de definições na raiz da solução. fucini-coverage.json ao lado da solução é lido depois de .vscode/settings.json e escrito pela janela de definições quando é o ficheiro que existe — para uma equipa que prefira não manter uma pasta .vscode. Ambas as edições o leem.
• .NET sem cerimónias. ignore.generated deixa os ficheiros de designer, os gerados, obj\ e as migrações fora de cada total; testRun.skipWhenTestsFail mantém no ecrã a última cobertura boa quando uma execução termina a vermelho.

Ainda não nesta edição

• O painel Test Coverage é uma API do VS Code, e o Solution Explorer não consegue mostrar distintivos. Compare Two History Runs segue-se quando os subscritores o pedirem.

Adicionado

• Que ficheiros mostrar. Uma segunda lista pendente na barra de ferramentas da vista Coverage, ao lado da ordenação: todos os ficheiros, os ficheiros com lacunas, os ficheiros não testados, ou os ficheiros cujos números mudaram desde a execução anterior. As pastas seguem os seus ficheiros e mantêm os seus próprios números. Em todos os planos.
• Risk hotspots. Sob a árvore: as funções onde código complexo se encontra com pouca cobertura, da pior para a melhor, cada uma abrindo o seu ficheiro na função. Uma função qualifica-se pela pontuação CRAP — hotspots.crapThreshold, 30 por predefinição, o valor que os autores da métrica propuseram — ou só pela complexidade ciclomática, hotspots.complexityThreshold, desligado por predefinição. A Community vê a contagem e a pior pontuação; a lista ordenada é Pro.
• dotnet test sem pacote. Run Tests with Coverage lê primeiro os ficheiros de projeto: onde nenhum referencia o Coverlet, a execução usa o coletor da própria Microsoft — --collect:"Code Coverage;Format=cobertura" — que vem com o Microsoft.NET.Test.Sdk, e o seu relatório é carregado como o do Coverlet.
• Os ficheiros .NET gerados ficam de fora. ignore.generated, ativo por predefinição, retira *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, os usings globais, tudo o que está sob Migrations/ e sob obj/ de cada total, página e exportação. Um ficheiro de designer que ninguém testa já não custa a uma solução o seu gate.
• Uma execução falhada mantém a última cobertura boa. Com testRun.skipWhenTestsFail, uma execução que termina com um teste falhado deixa a cobertura no ecrã tal como estava, e di-lo no painel Output. Desligado por predefinição.

Alterado

• Uma execução do Test Explorer é encontrada por si. Sem nada configurado, os nomes conhecidos incluem agora a pasta TestResults/<run>/ de cada projeto de testes, não só a da própria pasta do espaço de trabalho, e o <user>_<machine>_<date>.cobertura.xml do coletor da Microsoft ao lado do do Coverlet. Uma solução .NET cujos testes foram executados no Visual Studio mostra a sua cobertura logo na primeira abertura; cada pasta de execução é carregada, e a fusão mantém para cada ficheiro o que diz a execução mais recente.

Adicionado

• Uma segunda extensão, para Visual Studio 2022 e 2026 — Community, Professional e Enterprise. O mesmo leitor da edição para VS Code, por isso o mesmo relatório dá os mesmos números, ao dígito, nos dois editores; e as mesmas definições fuciniCoverage.*, lidas de .vscode/settings.json e das definições de utilizador do próprio VS Code quando está na máquina. Não usa a cobertura de código própria do Visual Studio: no Visual Studio 2022 é uma funcionalidade Enterprise, e no Community e no Professional esta é a única cobertura que o IDE mostrará.
• No editor: uma barra na margem por linha — vermelha nunca correu, âmbar em parte, um mapa de calor por visitas — contagens em linha, uma linha acima de cada função com a sua cobertura, complexidade, pontuação CRAP e MC/DC, riscas na barra de deslocamento, um hover que diz qual o ramo que não foi tomado, e um ponto numa linha que editou desde o relatório.
• A janela Coverage (View → Other Windows → Coverage): cada ficheiro com as suas métricas e uma pontuação sobre todos, ordenável, com os ficheiros não medidos por baixo; os itens Coverage e File da barra de estado, cada um a abrir o cartão completo.
• Comandos em Tools → Coverage Studio, com acordes de duas teclas após Ctrl+Shift+U: N/P para a linha não coberta seguinte e anterior, B para a próxima decisão parcialmente testada, R para recarregar. O modo de vigilância recarrega quando o ficheiro que a sua build escreve muda.
• Getting Started, os seis passos com um botão para cada um, em 18 idiomas; abre-se sozinho da primeira vez.
• Definições a partir da engrenagem na barra de ferramentas da janela Coverage, que escreve as definições de utilizador desta edição ou o .vscode/settings.json da pasta e mantém os comentários de um ficheiro que edita.
• Licença: incluída em todos os planos pagos. Uma máquina onde o Coverage Studio para VS Code está ativado não precisa de mais nada — a chave é encontrada sozinha; em qualquer outro lado, Tools → Coverage Studio → Licence… aceita o código de subscrição do seu e-mail de ativação. Sem subscrição não se lê cobertura: não há nível gratuito no Visual Studio.

Ainda não nesta edição

• Run Tests with Coverage e o painel Test Coverage são APIs do VS Code; o Solution Explorer não consegue mostrar distintivos. A vista Annotated Source, o relatório HTML e as exportações, Check Thresholds, as entradas da Error List, histórico e tendência, e a cobertura de diff seguem pela ordem em que os subscritores as pedirem.

Adicionado

• Um passo a passo. Get started with Coverage Studio — em Help → Welcome → Walkthroughs, e aberto sozinho depois da instalação — leva um utilizador novo em seis passos de um relatório de cobertura às linhas que ninguém testa, cada um com um botão para o comando de que trata. Em todos os dezoito idiomas.
• O id de instalação é deixado onde o Coverage Studio para Visual Studio o lê. A edição para Visual Studio verifica a chave em license.key contra a mesma impressão digital e não consegue ler o armazenamento de estado desta extensão; em cada ativação o id passa a ser escrito também ao lado do armazenamento global da extensão, por isso uma máquina ativada no VS Code não precisa de uma segunda ativação no Visual Studio. Um UUID aleatório, ligado a nada, nunca enviado a lado nenhum.

Alterado

• Um reembolso termina a subscrição. Um reembolso ou chargeback aprovado cancela agora a subscrição de imediato e o seu código de ativação não emite mais chaves; os reembolsos são um por cliente. As chaves já numa máquina continuam até à sua própria expiração, como antes. A política de reembolsos diz exatamente o que acontece.

Corrigido

• Os nomes dos ficheiros na vista Coverage leem-se com qualquer largura. O nome era a única parte de uma linha que encolhia — até sete caracteres numa barra lateral comum. Agora é desenhado por inteiro, e as colunas de métricas, a pontuação e a barra deslizam por baixo dele a partir da esquerda, esbatendo-se no corte para que meio número nunca se leia como um número inteiro. Todos os valores continuam na dica da linha.
• A marca «o ficheiro foi alterado» acompanha o ficheiro. Depois de um carregamento seguia a primeira edição e o primeiro restauro, e depois nada a movia até ao carregamento seguinte. Agora cada gravação e cada alteração no disco chega.
• A barra de ferramentas da vista Coverage já não parte as etiquetas dos botões. Numa barra lateral estreita, a barra passa agora para a linha seguinte entre os seus controlos, e a caixa de ordenação fica numa linha própria.
• O emblema de cobertura também é gratuito no seletor de exportação. Generate Coverage Badge sempre escreveu o emblema SVG em todos os níveis, enquanto Export Coverage Report… recusava o mesmo ficheiro no Community. Agora ambos o escrevem.
• Show Worst-Covered Folders é licenciado como as outras duas listas. Nada muda no Community, onde as três são gratuitas e não contadas, nem para nenhuma chave já emitida.

Adicionado

• Uma versão mínima suportada. A extensão lê agora, cerca de uma vez por semana, uma pequena política assinada do nosso servidor de licenças. Quando uma compilação é mais antiga do que a mais antiga ainda suportada, o período de avaliação e o nível gratuito param e pedem uma atualização; a uma licença paga é indicada a data e continua primeiro a funcionar durante um período de tolerância. A leitura não envia nada sobre si nem sobre a sua instalação, e uma instalação que não consegue chegar ao servidor nunca é parada por esse motivo. Hoje não está definido nenhum mínimo.

Alterado

• A licença é proprietária a partir desta versão. A extensão era publicada sob os termos MIT, que nunca corresponderam a um produto vendido por subscrição. Pode instalar e usar a compilação publicada dentro do seu plano, também para fins comerciais; não pode copiá-la, modificá-la, redistribuí-la nem fazer-lhe engenharia inversa. O que ela produz a partir dos seus dados — relatórios, exportações, emblemas — é seu, e a antiga condição de atribuição desaparece. Uma cópia de uma versão anterior continua sob os termos com que veio.
• O botão de ações de caminho (⋯) não ocupa espaço até apontar para uma linha. Os 25 píxeis que mantinha reservados em cada linha passam para o nome do ficheiro; aparece logo a seguir ao nome ao passar o ponteiro, e nada se move na linha.

Corrigido

• Os tracefiles LCOV 2 listam cada função uma só vez. FN:<linha>,<linha final>,<nome> é lido tal como o lcov 2.0 o escreve — antes cada função aparecia duas vezes, uma como nunca chamada e outra na linha 0 — e os pares FNL:/FNA: do lcov 2.2 são lidos com ele.
• Um template C++ já não é pintado como nunca executado por uma instanciação não o ter sido, e uma função cheia de macros volta a ser uma função em vez de uma por macro.
• Os textos de consentimento dizem o que a instalação envia de facto: nenhuma página mensal do seu código, e o resumo de utilização leva o código de pedido com que a sua chave foi emitida.

Adicionado

• A cobertura de condições é uma métrica própria. a && b é uma decisão e duas condições, e um conjunto de testes pode percorrer ambos os ramos sem nunca ver b falso. Tem agora linha, coluna, exportações, emblema, peso na pontuação (3, entre ramos e MC/DC) e limiar próprios — lida do BullseyeCoverage, de uma exportação cond do TRACE32 e do -fcondition-coverage do GCC 14.
• Mutantes, onde estão. Os relatórios do PIT e do Stryker são lidos mutante a mutante: os sobreviventes são marcados na sua própria linha no editor, com a alteração e os testes que a executaram na dica, e listados no relatório HTML e no código anotado.
• Que testes executaram esta linha. O coverage.py com --show-contexts e o OpenCover com -coverbytest dizem que testes chegaram a uma linha; a dica com o número de execuções nomeia-os.
• A parte de uma linha executada que nunca correu é tingida no editor, e as funções de C e C++ ganham complexidade e pontuação CRAP contadas a partir dos dados de ramos que o llvm-cov já traz.
• Os projetos JaCoCo, Cobertura e Coverlet carregam à primeira abertura, sem nada configurado — incluindo onde o Maven, o Gradle e o dotnet test escrevem por omissão.
• Cada métrica ao lado de cada ficheiro, com qualquer largura, ordenada pelo peso que tem na sua pontuação, com o que não cabe a deslizar em vez de desaparecer — e uma contagem no ícone Coverage quando um tracefile recarrega enquanto olha para outra coisa.
• Um canal de pré-lançamento ao qual se pode voluntariar e um botão na barra de título do editor que desliga a pintura da cobertura e devolve exatamente o que estava.

Alterado

• Bullseye e TRACE32: a cobertura de ramos deixa de incluir condições. As decisões são cobertura de ramos e as condições cobertura de condições, pelo que o valor de ramos de um projeto assim muda, e com ele a pontuação composta. Defina whmWeights.conditions como 0 para a pontuação como era.
• O nível gratuito Community tem uma dotação semanal: cinco por semana de cada ação medida, onde eram vinte por dia, e no limite é oferecida uma subscrição ou um passe de 7 dias. Uma instalação já em uso mantém os limites antigos durante 30 dias e é avisada uma vez, com a data.
• A avaliação e o nível gratuito mantêm um registo de utilização com o servidor de licenças: um hash do id de máquina do VS Code, a edição, o dia em que a avaliação começou e os contadores das ações medidas — nada mais, nunca numa licença paga e nunca esperado. A troca por telemetria é agora de 30 dias, uma só vez.
• A página mensal de código-fonte desapareceu — deixou de ser recolhida, guardada ou enviada, para quem quer que seja, e a que uma versão anterior tenha guardado é apagada no primeiro arranque desta.

Corrigido

• O mapa de calor lê-se no sentido certo num tema escuro. A sua gama ia do amarelo pálido ao castanho escuro, pelo que o ciclo mais quente tinha a barra mais apagada. Um tema escuro tem agora uma gama própria, do verde-azeitona esbatido ao laranja vivo.
• A informação de MC/DC ao passar o cursor volta a mostrar o seu detalhe, e uma decisão do llvm-cov conta corretamente as suas condições. O VS Code atual recolhia essa informação numa única linha; e (a && b) || c era listada com uma condição a 100% sob um título que dizia, e bem, 2 de 3 pares.
• As funções C++ têm o nome com que as escreveu: clamp_to<int> e gearbox::next_gear em vez do ??$clamp_to@H@@YAHHHH@Z do linker, para llvm-cov, lcov e gcov.
• As contagens de linhas do Istanbul coincidem com as do nyc, o XML do dotnet-coverage é lido, as linhas :nocov: do SimpleCov são excluídas em vez de danificadas, e um relatório que só contém um resumo mantém os seus valores seja qual for a ordem em que os relatórios são lidos.
• Áreas de trabalho com várias pastas raiz: o relatório HTML já não nomeia uma pasta duas vezes, a vista Coverage encabeça uma pasta da área de trabalho com o respetivo nome, e uma regra pathRemap pode indicar ${workspaceFolder} além de ${workspaceRoot}.

Adicionado

• Tudo o que um relatório contém é mostrado. Chamadas de funções, código-objeto e uma pontuação de mutação passam a ter uma coluna na vista Coverage, no relatório HTML e nas exportações CSV e Markdown, uma linha nos cartões da barra de estado e um distintivo no código-fonte anotado — e uma métrica que um relatório não contém é omitida em vez de ser impressa como zero.
• Complexidade e CRAP. Quando um relatório contém a complexidade ciclomática (OpenCover, JaCoCo, Clover, Cobertura), cada função recebe uma pontuação CRAP no seu CodeLens, um ficheiro recebe um Max CRAP com ligação ao método, e o relatório HTML lista os Riskiest Methods.
• Mais de cada formato: braços de ramo com nome, linhas excluídas, intervalos de colunas dentro da linha, a ferramenta, a versão e a data do relatório, e os avisos que uma ferramenta nele escreveu.
• Pesos opcionais para o código-objeto e a pontuação de mutação na pontuação composta, ambos a 0 a menos que os defina.

Alterado

• Os limiares predefinidos já não são 100%. Um limiar que não tenha definido vale agora linhas 80, funções 80, regiões 75, ramos 70 e pontuação composta 75, sem qualquer gate para MC/DC, instanciações, chamadas de funções ou código-objeto — o que se pode exigir de um projeto comum. fuciniCoverage.threshold.profile: "safety" repõe todos os gates em 100, exatamente como antes, e um limiar que tenha definido prevalece sobre qualquer dos perfis. Se dependia das predefinições antigas, é avaliado com mais benevolência até selecionar safety; uma instalação que já tenha sido utilizada antes é informada disso uma única vez, com um botão que o define.
• Uma métrica sem gate mostra um traço neutro nos cartões em vez de um visto ou de uma cruz, e o painel de definições pré-visualiza o veredicto com os gates efetivamente em vigor.

Corrigido

• A cobertura num buffer com alterações por guardar volta a alinhar. Uma execução carregada enquanto um ficheiro tinha edições por guardar deslocava cada marca, dica e CodeLens tantas linhas quantas essas edições os tinham empurrado. As edições são agora recuperadas do ficheiro em disco, e uma linha inteira colada acima de outra deixa de contar essa linha como editada.
• As fusões e os registos LCOV repetidos somam-se. Um ficheiro de rastreio mais recente deixa de manter os resumos de ramos e MC/DC da execução anterior, e um ficheiro listado duas vezes no mesmo ficheiro de rastreio é combinado como o genhtml o combina.
• A chave de licença fica na sua máquina. O Settings Sync deixa de a levar para outras instalações, onde bloqueava a cobertura; uma chave Business, Enterprise ou Pro Plus expirada renova-se sozinha até 45 dias após expirar.
• Os ficheiros de rastreio remotos são obtidos com mais cuidado. Os remote.headers ficam na sua origem através de redirecionamentos, uma obtenção desiste ao fim de 30 segundos, uma página de início de sessão é recusada em vez de guardada em cache, e uma janela aberta offline carrega a última cópia descarregada. A atualização automática instala apenas a sua própria edição.
• Analisadores: as contagens de linhas do llvm-cov coincidem com llvm-cov show, as decisões OpenCover de métodos diferentes deixam de se sobrepor, xccov, TRACE32 e EMMA mantêm os seus valores de linhas, as classes Cobertura que partilham um ficheiro são um só ficheiro, os relatórios agregados JaCoCo são lidos, e o mapeamento de caminhos resolve .. e compara segmentos inteiros.
• No editor: o histórico é mantido por área de trabalho, as marcas ficam em ficheiros reais e não no painel HEAD de um editor de diferenças, as linhas para lá do fim de um ficheiro não são pintadas, os distintivos do Explorador no Windows funcionam com caminhos C:\…, e as execuções grandes consultam-se mais depressa.

Adicionado

• Enviar relatório de diagnóstico. As notificações de um carregamento, obtenção remota, fusão, comparação de histórico ou chat falhados oferecem-no. Mostra exatamente o JSON que seria enviado, com uma amostra de ficheiro de 4 KB opcional, comentário e endereço de resposta, e não envia nada até clicar em Enviar.
• Relatórios de erro. Um erro FUCINI_* é comunicado sem conteúdo de ficheiros, caminhos nem nomes quando o nível de telemetria do VS Code é all ou error. Três linhas de registo têm código próprio: FUCINI_REMOTE_002, FUCINI_REMOTE_003 e FUCINI_GITDIFF_002, cada um descrito no guia do utilizador.

Alterado

• Toda a percentagem de cobertura tem duas casas decimais, truncadas em vez de arredondadas: 87.43%, e 100.00% apenas quando a cobertura é exatamente 100.
• Os limiares decidem sobre o valor exato. Até agora cada percentagem era primeiro arredondada a um inteiro, pelo que 89,6% passava um limiar de 90%. Um projeto que só passava por arredondamento mostra agora NON-COMPLIANT até a sua cobertura atingir realmente o limiar.
• A telemetria é diária. Cada instalação envia uma pequena mensagem de licença diária no nível de telemetria all do VS Code; com telemetry.enabled ligado, o resumo de utilização sai diariamente em vez de mensalmente. As instalações que desbloquearam funcionalidades por telemetria são consultadas antes de as suas condições mudarem.

Adicionado

• A vista Coverage avisa quando há uma atualização, e continua avisando. Uma barra acima do banner de licença mostra a nova versão ao lado da que você tem, com os mesmos três botões da notificação de atualização: “Transferir & instalar”, “Ver registo de alterações” e “Ignorar esta versão”. O ícone da vista na barra de atividades também ganha um selo, então ele aparece mesmo com a vista fechada. A notificação aparecia só uma vez, na verificação automática, e um clique em qualquer outro lugar a escondia até a verificação seguinte, um dia depois; a barra fica até a atualização ser instalada ou ignorada, ou até fuciniCoverage.update.checkForUpdates ser desativado, e continua lá depois de recarregar a janela.

Alterado

• Os pings pequenos saem no máximo uma vez por dia, juntos. Uma atualização, uma mudança de licença, um novo formato de cobertura e um arquivo que não pôde ser lido eram, cada um, um ping próprio, enviado assim que era notado — e, em algumas instalações, notado de novo a cada sessão: um assento revogado informava sua revogação a cada inicialização, e alternar entre áreas de trabalho com formatos diferentes informava a cada vez um conjunto “novo”. Agora eles são reunidos e enviados como um único ping, no máximo uma vez por dia. Um dia sem nada a informar não envia nada.
• Só é informado o que realmente mudou. Uma licença que muda e volta ao estado anterior no mesmo dia não informa nada, e os formatos são todos os que a instalação já carregou, e não apenas os da última área de trabalho. O ping de instalação e o aviso de remoção continuam saindo imediatamente, e nada de novo é coletado.
• O próprio botão de telemetria do VS Code agora vale também para os pings pequenos. Com telemetry.telemetryLevel em off, nada é coletado para o ping diário e nada é enviado; até agora, só o resumo mensal e o aviso de remoção o respeitavam. O ping de instalação único não mudou.
• Um mês que termina enquanto o editor está parado ainda é informado. O resumo mensal só era verificado depois de carregar cobertura, então uma instalação que deixou de ser usada nunca enviava seu último mês. Agora ele também é verificado a cada hora enquanto o VS Code está aberto — ainda apenas com a telemetria ligada, e ainda no máximo uma vez a cada 30 dias.

Corrigido

• Um ping recusado pelo servidor não conta mais como enviado. Qualquer resposta do servidor, inclusive um erro, era tomada como entrega, então um ping diário recusado perdia o que tinha coletado e um ping de instalação recusado não era tentado de novo. Agora só uma resposta bem-sucedida conta; um ping diário ou resumo mensal recusado é mantido e tentado de novo um dia depois.

Alterado

• Cada avaliação recebe 14 dias novos, uma vez. Na primeira vez que esta versão arranca, o período experimental reabre em cada instalação Pro sem licença paga — quer tenha terminado há muito, quer ainda lhe restassem alguns dias — e dura 14 dias a partir desse dia. Um breve aviso indica-o quando acontece. Uma licença paga fica intocada, e a edição Community, que não tem período experimental, mantém-se inalterada.
• Uma licença paga diz «Ativado», a verde. O banner de licença mostrava a um subscritor «Ativado — faltam 30 dias». Uma chave de subscrição vale até ao fim do período pago e é renovada com ele, pelo que essa contagem decrescente nunca deixaria de se ler como um período experimental prestes a terminar. O título diz agora apenas Ativado, a data aparece nos detalhes como «Em vigor até», e a contagem decrescente só volta na última semana antes de uma chave expirar, ao lado da nota de renovação próxima que já lá estava.

Adicionado

• «Enter Subscription Code» — e nada mais lhe é pedido. Escolha o plano, cole o código do e-mail de compra, confirme, e a sua chave de licença é emitida e aplicada por si. Até agora a única via a partir do editor era o questionário de avaliação — nome, e-mail, tipo de conta, empresa, um inquérito —, que é o formulário errado para pôr à frente de quem já comprou. A outra via era a ligação vscode:// do e-mail, e desconfiar desse clique é sensato e não medroso: uma ligação assim pode ser desencadeada por qualquer página que visite, e é precisamente por isso que a ativação lhe pede confirmação. O comando está na paleta de comandos e é um botão no banner de licença do painel de cobertura e na caixa de diálogo de ativação — em todos os estados, porque uma licença muda de máquina e comprar a meio do período de avaliação é o caso comum, não a exceção.
• Uma forma de ver os planos a partir do próprio período de avaliação. A página de preços era acessível a partir dos ecrãs da edição gratuita, mas não da caixa de diálogo de ativação nem do banner de licença — o único lugar onde olha de facto quem lê «faltam 3 dias». A esse leitor ofereciam-se um questionário e uma indicação sobre settings.json, e preço nenhum.

Alterado

• A caixa de diálogo de ativação e o banner de licença já não abrem com FCK1. Ambos começavam pelo seu código de pedido e por «cole a chave em settings.json», que é o caminho para quando o nosso servidor de licenças não pode ser alcançado de modo algum. Mostrado primeiro, lia-se como a instrução — pelo que um cliente com um código de subscrição FCB1… era mandado para «Enter Activation Key», o único campo que havia de o recusar. Ambos continuam lá, abaixo das vias que servem quem já comprou, e descritos como aquilo que realmente são.

Corrigido

• «Request Activation Key» é agora realmente um comando. O e-mail de compra — e a página de ativação, em todas as línguas — dizem-lhe que, se a ligação de um clique não sobreviver ao programa de e-mail, pode executar Fucini Coverage: Request Activation Key na paleta de comandos, escolher o plano e colar o código. Esse nome pertencia à barra de título do painel e à própria ligação, nunca a um comando, pelo que a paleta não tinha nada por baixo dele — e a correspondência mais próxima pelo nome, Enter Activation Key, aceita a chave FCK1… emitida pelo nosso servidor e não o código FCB1… que o e-mail transporta. Seguir as instruções levava-o exatamente ao único campo que havia de recusar o que tinha na mão. Agora é um comando a sério.
• A caixa de diálogo de ativação oferece Solicitar licença… enquanto um período de avaliação ou uma chave ainda estão válidos. Antes era retida até um deles expirar, com o raciocínio de que uma instalação a funcionar não tem motivo para contactar o servidor de licenças. Mas comprar a meio do período de avaliação é o caso comum e não a exceção, e quem estava nessa situação não tinha, a partir da caixa de diálogo, nenhum caminho até ao campo onde entra o seu código: os dois botões que restavam pediam uma chave que só o resgate do código produz.

Adicionado

• Uma paleta para daltónicos. Defina colorScale.preset como colorblind e a cobertura passa a ser desenhada em vermelhão, laranja e azul (a paleta Okabe–Ito) em vez de vermelho, âmbar e verde — o gradiente, as barras na margem, o realce das linhas, os distintivos do Explorador e as marcas desde a última execução. Uma cor que tenha definido tem prioridade.

Adicionado

• Filtrar a cobertura por teste na vista Test Coverage do VS Code. Quando um ficheiro de trace nomeia os seus testes — as secções TN: do lcov —, cada teste passa a ser um item em Fucini Coverage no Test Explorer, cada ficheiro na vista Test Coverage lista os testes que nele executaram algo e escolher um mostra as linhas que esse teste alcançou.
• ${command:…} nas definições de caminho. ${command:cmake.buildDirectory}/coverage.info acompanha o kit CMake selecionado. O comando é executado antes de cada descoberta, no máximo cinco segundos e apenas numa área de trabalho fidedigna; um comando que falhe deixa a variável tal como está escrita, e a saída diz porquê.
• Um arranque rápido de 30 segundos e uma comparação com as alternativas abrem agora a página do Marketplace e a página inicial.

Corrigido

• Um ficheiro de trace que registava um ficheiro uma vez por teste contava-o uma vez por teste. Os registos passam a ser somados por ficheiro de trace, como o genhtml os lê: o ficheiro conta uma só vez nos totais e, com vários ficheiros de trace carregados, nenhum teste perde as suas linhas.

Corrigido

• O ID de instalação passa a ser guardado antes de algo o usar. A build 2 da 0.2026.72 deixou de recalcular o ID a cada chamada, mas o arranque continuava a não esperar que fosse escrito, pelo que uma janela fechada logo após abrir ainda o podia perder — e com ele a impressão digital da máquina à qual a chave de ativação está associada. O arranque agora espera.
• Mudar de Pro para Community mantém a chave de ativação válida. Cada edição tem o seu próprio armazenamento de extensão, por isso a Community começava com um novo ID de instalação e uma nova impressão digital, enquanto a chave nas definições — incluindo a que a mudança acabara de pedir para o desbloqueio gratuito — estava associada ao antigo. A mudança passa agora o ID.

Segurança

• As atualizações de fucini.software são assinadas e verificadas antes de serem instaladas. Cada .vsix no canal de atualizações traz um hash SHA-256 e uma assinatura Ed25519 feita com uma chave que nunca está no servidor web. O atualizador integrado e a mudança para Community verificam ambos contra o ficheiro transferido e recusam tudo o resto — a página de erro de um proxy, uma transferência truncada, uma build antiga em cache ou um ficheiro que não é nosso. O HTTPS por si só não cobre isto: um proxy empresarial que inspeciona TLS volta a assinar cada ligação que vê.
• Cada versão tem o seu próprio nome de ficheiro. O canal de atualizações aponta agora para um .vsix com número de versão em vez de um ficheiro substituído a cada versão, pelo que uma cache que ignore Cache-Control não pode servir a build do mês passado como a deste mês. As ligações na página de transferências mantêm-se.

Adicionado

• Saltar para as decisões testadas num só sentido. Next Partly-Tested Decision e a sua gémea anterior percorrem as ramificações de que alguns ramos foram executados e outros nunca. É a lacuna que a navegação por linhas não cobertas não consegue mostrar: uma linha cuja instrução foi executada está coberta, e continua a estar por muitos ramos seus que nunca tenham sido tomados — if (a && b) alcançado uma vez com a falso está 100% coberto por linhas e testado a meio. Uma paragem por decisão em vez de por ramo, porque os ramos de um if/else podem estar a páginas de distância, e saltar para o quinto ramo de um switch diz menos do que saltar para o próprio switch. As decisões que nenhum ramo alcançou ficam para os comandos de linhas não cobertas, que já param aí — e um ficheiro cujo relatório não regista ramificação alguma di-lo, em vez de afirmar que cada decisão foi testada nos dois sentidos.
• Reload Coverage relê o que já está carregado. Com a vigilância desligada, o único caminho de volta a números frescos depois de reexecutar os testes era Load Coverage, que repete a deteção e pode voltar com um conjunto diferente do que está no ecrã. Este comando relê exatamente o que está carregado agora, incluindo ficheiros de rastreio escolhidos à mão que a deteção nunca voltaria a encontrar.
• Copy Coverage Summary põe a execução numa tabela Markdown. O ficheiro pior coberto primeiro, com uma linha de totais, pronto a colar num pull request. As colunas de ramos e de MC/DC só aparecem quando algo na execução as mediu: uma coluna de travessões lê-se como cobertura zero em vez de não medida, o que é o oposto da verdade.

Corrigido

• O identificador de instalação podia mudar entre sessões — e é dele que se deriva a impressão digital da licença. Era determinado de novo em cada chamada e guardado sem que nada esperasse pela escrita, pelo que uma segunda chamada, ou uma janela do editor fechada pouco depois do arranque, podia criar um novo. Um identificador que muda é uma chave de ativação que deixa de corresponder; inflacionava ainda todos os números contados por instalação. É agora fixado uma vez por sessão e guardado antes de algo o usar. Compilação 2.

Adicionado

• Atribuição de origem ao nível da linha. Com mais de um tracefile carregado, a dica com a contagem de execuções termina agora com Coberto por: e os relatórios que registaram uma execução nessa linha — e clicar numa linha de tracefile na vista Coverage ilumina agora as linhas que ele contribuiu, em cada editor aberto, tal como já iluminava os ficheiros que mediu. É a única pergunta a que uma execução combinada consegue responder e um relatório isolado não: dois tracefiles que medem o mesmo ficheiro discordam quanto às suas linhas, e até agora a combinação achatava essa discordância sem nunca a mostrar. A combinação continua a ser por ficheiro — o relatório mais recente ganha por completo um ficheiro partilhado — pelo que as origens por linha são indexadas antes dela. Só contam as linhas cobertas: um relatório que registou uma linha como 0 não a cobriu.
• O registo TN: do lcov é finalmente lido. Um tracefile que nomeia a sua suíte — TN:integration — aparece como coverage.info (integration) onde quer que uma origem seja nomeada, e o nome sobrevive a uma exportação de volta para lcov em vez de ser escrito vazio. A maioria das ferramentas escreve TN: vazio e não muda; as que o preenchem são exatamente aquelas cujos tracefiles são combinados, e então o nome é a única coisa que diz qual é qual.
• fuciniCoverage.lineHighlight tinge as próprias linhas. off | uncovered | heatmap, desativado por padrão: um tom translúcido atrás de cada linha não coberta e parcialmente coberta, e em heatmap também atrás de cada linha executada, mais quente quanto mais vezes executou. Uma opção própria em vez de um quarto valor de editorGutter.mode, porque são desejadas em pares diferentes: as lacunas tingidas com a margem limpa, ou barras sem cor atrás do código. Translúcido porque fica sob o texto, e tinge as lacunas em vez das linhas cobertas, pela mesma razão que a margem.
• fuciniCoverage.overviewRuler decide sozinho a faixa na barra de deslocamento. follow (padrão) faz o de sempre: uma faixa onde a margem desenha uma barra não coberta ou parcial, e nunca para o mapa de calor. uncovered pinta-a mesmo com editorGutter.mode desligado — um mapa das lacunas do ficheiro ao longo da barra de deslocamento e nada ao lado do código. off mantém as barras e remove a faixa. Antes a régua estava presa à margem, pelo que essas duas combinações não existiam.

Corrigido

• Um tracefile que não é possível analisar diz agora como foi lido. «…não está bem formado» deixava o leitor a adivinhar se o ficheiro tinha sequer sido reconhecido como o formato que julga — e um documento Cobertura recusado pelo analisador do VectorCAST é um problema diferente de um documento verdadeiramente truncado. A notificação termina agora com Foi lido como cobertura. quando algum analisador reclamou o ficheiro. Se nenhum o fez, nada é acrescentado: «não está num formato que esta extensão lê» já o diz por inteiro.

Corrigido

• O aviso de dados desatualizados na dica da barra de estado volta a mostrar o seu ícone de relógio, em vez do texto $(history). O aviso que diz que os números abaixo descrevem uma versão mais antiga dos ficheiros leva a mesma marca $(history) que a própria barra de estado. Na barra de estado essa marca é desenhada como o ícone de relógio, porque StatusBarItem.text substitui os ícones por si; a dica é um MarkdownString, que tem de aderir a isso com supportThemeIcons e nunca aderiu — pelo que a única linha que explica por que razão a cobertura não é de confiança começava com um pedaço de sintaxe em bruto. A dica adere agora.

Adicionado

• A própria margem do editor pode agora mostrar as linhas não cobertas, ou um mapa de calor de contagens de acertos. Por predefinição continua a mostrar apenas constatações — barras MC/DC, triângulos de desde-a-última-execução, pontos de linhas editadas — e a vista a cores de um ficheiro inteiro continua a ser o Annotated Source. fuciniCoverage.editorGutter.mode permite mais: uncovered põe uma barra em cada linha que nunca correu e uma âmbar em cada linha com um ramo nunca tomado, e nada nas linhas cobertas, para que uma parede verde não esconda as três vermelhas; heatmap acrescenta um tom quente a cada linha executada, tanto mais quente quanto mais vezes correu. Choose Editor Gutter Mode... alterna entre os três a partir da paleta ou do menu da barra de estado. O README afirmava sem mais “margens nativas”; agora diz o que existe de facto.
• Contagens de acertos em linha. fuciniCoverage.hitCounts.inline escreve ×12 a seguir a cada linha em que começa uma instrução, ×0 incluído — o número que sempre esteve na dica ao passar o rato, sem passar o rato. Toggle Inline Hit Counts alterna-o; o menu da barra de estado oferece-o como Mostrar ou Ocultar, consoante o que se aplique.
• ${env:NAME}, ${config:section.key}, ${userHome} e ${workspaceFolderBasename} em todas as definições de caminho, ao lado do ${workspaceFolder} que já lá estava. Uma variável que a extensão não conhece fica tal como foi escrita, pelo que uma gralha aparece no registo de deteção como o caminho que procurou, em vez de desaparecer.
• Uma entrada de coverageFile.paths pode ser um URL http(s)://. O artefacto é descarregado para o armazenamento da extensão em cada carregamento e carregado a partir daí; a vista Cobertura mostra o URL, não o caminho da cache. Cada descarga é condicional (ETag / Last-Modified), pelo que voltar a pedir um artefacto inalterado não descarrega nada, e quando uma descarga falha é carregada a última cópia descarregada e o motivo fica na saída. fuciniCoverage.remote.headers acrescenta cabeçalhos Name: value com as variáveis expandidas — Authorization: Bearer ${env:CI_TOKEN} mantém o token fora do settings.json — e fuciniCoverage.remote.refreshMinutes volta a descarregar por temporizador. Acrescente #lcov.info (ou outro nome de ficheiro) como fragmento do URL quando o próprio URL não termina num, para que o formato seja conhecido.
• O carregamento e o Generate Full HTML Report mostram progresso e podem ser cancelados. Um carregamento de dez ou mais ficheiros de cobertura, ou de 8 MB ou mais deles, corre sob uma notificação de progresso com um botão Cancelar que indica o ficheiro a ser lido e a fase (leitura, depois verificação das fontes); um mais pequeno apenas faz girar a barra de estado como antes. Cancelar deixa a execução anterior carregada e di-lo. O relatório HTML faz o mesmo por cada página renderizada e escrita.
• Mais dois motivos para recarregar. Uma entrada absoluta de coverageFile.paths fora da área de trabalho — uma árvore de compilação ao lado do checkout, uma raiz de saída do Bazel — passa a ser sondada também, pelo que um ficheiro que aí apareça depois de a janela abrir é carregado em vez de nunca mais ser procurado; o observador só alguma vez viu a área de trabalho. E fuciniCoverage.watch.reloadAfterTasks nomeia tarefas (um label do tasks.json, ou source: name tal como a lista Run Task o mostra, p. ex. npm: test) cujo fim recarrega a cobertura, esteja ou não watch.enabled ligado — para compilações que o observador não consegue seguir: uma execução que substitui uma árvore de saída com ligações simbólicas, um relatório numa partilha de rede, um passo de cobertura que pós-processa o seu ficheiro.
• Áreas de trabalho multi-raiz. Cada pasta de uma área de trabalho é agora detetada nos seus próprios termos: coverageFile.defaultLocation, coverageFile.paths, pathRemap, ignore, watch.*, remote.*, badge.*, os diretórios de relatório, gitDiff.*, problems.perLine, editorGutter.mode e hitCounts.inline são lidos por pasta, pelo que o .vscode/settings.json da própria pasta ou a sua entrada no .code-workspace se aplica; ${workspaceFolder} significa a pasta da própria entrada; os ficheiros de cobertura encontrados em todas as pastas fundem-se numa só execução, e a vista Cobertura agrupa os ficheiros por pasta. ${workspaceRoot} numa regra de pathRemap tenta primeiro a pasta do próprio ficheiro de cobertura, depois as outras. Tudo o que precisa de uma só pasta — os diálogos de ficheiros, a saída do relatório e do emblema, os metadados do git, Run Tests with Coverage — usa a do editor ativo, e com várias pastas e nenhum editor a execução de testes pergunta qual. Uma pasta adicionada à área de trabalho ou dela removida recarrega a cobertura por si. Antes disto, doze sítios usavam a primeira pasta e uma segunda raiz recebia a base errada para tudo.
• A execução é publicada na própria vista Test Coverage do VS Code. Com fuciniCoverage.testCoverage.publish (ligado por predefinição), cada execução carregada vai também para o painel Test Coverage nativo, as suas percentagens por ficheiro no Explorador e o próprio botão “Show Inline Coverage” do editor — linhas, ramos e funções, com os detalhes carregados a pedido. Show in Test Coverage View publica a execução ativa e abre o painel, diga a definição o que disser; o menu da barra de estado oferece-o atrás de quickActions.showTestCoverage.
• É sugerida uma regra de remapeamento de caminhos quando os ficheiros não correspondem. O mais comum “carregou mas nada se acende” é um ficheiro de cobertura cujos caminhos vêm de um contentor ou de um checkout de CI (/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c) enquanto a área de trabalho tem src/a.c. Quando um carregamento deixa ficheiros sem correspondência, a extensão procura os nomes dos ficheiros na área de trabalho, infere a regra de prefixo que explica o maior número deles, regista-a como [FUCINI_REMAP_002], e o resultado do carregamento oferece Apply Suggested Remap — um clique acrescenta a regra a fuciniCoverage.pathRemap e recarrega. Suggest Path Remap Rule corre a mesma análise a pedido. Nada é escrito sem o clique.
• fuciniCoverage.ignore: ficheiros que nunca contam. Ficheiros vendorizados, gerados ou de terceiros (vendor/**, **/*.generated.ts, build/**) são retirados da execução ao carregar, pelo que a vista Cobertura, a barra de estado, os limiares, os emblemas, o CodeLens, o histórico e as exportações contam todos sem eles; o resultado do carregamento diz quantos ficaram de fora e a saída nomeia-os. Os padrões comparam-se com o caminho relativo à área de trabalho e com o caminho absoluto; um padrão sem / corresponde a um nome de pasta ou de ficheiro a qualquer profundidade, como no .gitignore. Para ficheiros inteiros — as linhas dentro de um ficheiro continuam a usar os marcadores de exclusão da própria ferramenta.
• Entradas por linha no painel Problems, opcionais. fuciniCoverage.problems.perLine (off, uncovered ou uncoveredAndPartial; desligado por predefinição) põe um diagnóstico de informação em cada bloco contíguo de linhas que nunca correram — uma função morta de quarenta linhas é uma entrada, não quarenta — e, no segundo modo, em cada linha cujo ramo nunca foi tomado. Só para os documentos abertos, para que uma execução de dois mil ficheiros não possa inundar o painel; as entradas acompanham as suas linhas à medida que o buffer é editado e desaparecem quando o documento fecha. A entrada por ficheiro atrás de problems.enabled não muda.
• Um emblema de cobertura para o README. Generate Coverage Badge escreve um SVG ao estilo shields para a execução ativa na área de trabalho (fuciniCoverage.badge.outputPath, por predefinição coverage-badge.svg), para um README o incorporar com ![coverage](coverage-badge.svg) e sem serviço alojado. badge.metric escolhe linhas, ramos, MC/DC ou a pontuação ponderada; a cor segue os patamares de colorScale; badge.autoUpdate reescreve-o após cada carregamento. O emblema SVG que o Export Coverage Report já oferecia partilha agora o mesmo renderizador.
• Não medido versus não coberto. Um ficheiro que nenhum teste alguma vez carregou não está de todo no ficheiro de cobertura, pelo que a extensão sempre o manteve à parte de um ficheiro medido com 0 acertos — e fora dos números, que é exatamente como um projeto com metade dos módulos sem testes se lê como “92%”. Agora a distinção vê-se: abrir um ficheiro desses põe not measured na barra de estado, e fuciniCoverage.unmeasured.mode decide o que mais acontece. list acrescenta um grupo Não medidos à vista Cobertura com cada ficheiro da área de trabalho de um tipo que a execução mediu e que a execução não contém, conta-os no resultado do carregamento, marca-os com ? no Explorador quando os distintivos estão ligados, e deixa threshold.unmeasuredFiles fazer falhar o Check Coverage Thresholds acima de um número à escolha. count vai mais longe: cada ficheiro desses junta-se à execução como 0% — uma linha não coberta por cada linha de código — pelo que a barra de estado, os limiares, os emblemas, o histórico, as exportações e a vista Test Coverage veem todos o número honesto; o ficheiro é desenhado como não medido em todo o lado, nunca como “já não corresponde à sua cobertura”. unmeasured.exclude deixa de fora os cabeçalhos e afins (**/*.h, **/*.hpp, **/*.hh, **/*.inl, **/*.d.ts por predefinição). Desligado por predefinição; o estado da barra de estado é a única alteração que está sempre ativa.
• A vista de Cobertura mostra o que a fusão fez. Desde a 0.2026.63, a repetição própria de um módulo carregada sobre uma execução do projeto inteiro substitui os números dessa execução para os ficheiros do módulo, e cada linha nomeava o relatório de onde vem — mas uma linha cujos números sobrepuseram um relatório mais antigo era igual a uma medida por um só relatório entre vários, e nada dizia quanto de um relatório tinha sido sobreposto. Agora o distintivo de tracefile dessa linha tem contorno; cada linha de tracefile acima da árvore conta o que a fusão fez com os seus ficheiros («42 ficheiros · 7 sobrepostos por um relatório mais recente», «7 ficheiros · sobrepõe 7 em relatórios mais antigos»); e clicar numa linha de tracefile realça na árvore completa os ficheiros que ela mediu, esbatendo os restantes, até novo clique. fuciniCoverage.coverageView.mergedMarks (ligado por omissão) desliga o contorno e o realce; as contagens ficam.

Corrigido

• Um usuário Business ou Enterprise agora é solicitado a informar seu código de convite, não o código da empresa. Desde 2 de setembro o servidor de licenças recusa o código da empresa compartilhado para um lugar Business ou Enterprise: um lugar reivindicado com ele não nomeava ninguém, então cada lugar de equipe agora está vinculado ao endereço para o qual foi convidado, e o código que ativa um deles é o código de convite FCI1… daquele e-mail. O questionário ainda rotulava o campo como “Código da empresa”, sugeria pedi-lo ao gerente e mostrava um placeholder FCB1… — mandando as pessoas colarem justamente o código que já não funciona e, quando o deixavam em branco, dizendo-lhes que informassem um código da empresa. Nos planos de equipe o campo agora se chama “Código de convite”, a dica diz de onde vem o código e que o código da empresa compartilhado não ativa um lugar, o placeholder mostra o formato FCI1…, e a mensagem de validação pede o código de convite. Pro pede seu código de subscrição por esse nome. Pro Plus não muda: mantém o código compartilhado de propósito. Todos os 17 idiomas de exibição trazem o novo texto.

Corrigido

• ${workspaceFolder} agora funciona em coverageFile.paths, como sempre funcionou em coverageFile.defaultLocation. As duas configurações ficam lado a lado e só uma delas documentava a variável, então as pessoas a escreviam em ambas — e uma entrada que começa com ${ não é absoluta, por isso entrava no glob de descoberta como literal sob a pasta base, não encontrava nada, e a extensão dizia que não havia cobertura. Tal entrada agora é expandida primeiro, o que a torna um caminho absoluto, e simplesmente verificada. Ela fica na configuração como foi escrita, não é escrita uma segunda vez em outra forma quando o mesmo arquivo é escolhido, e sai sozinha da configuração quando descarregada na visão Coverage.
• Um arquivo de trace configurado que não existe agora é informado na saída. Uma entrada com caminho errado falhava da única maneira que nada relatava: “nenhuma cobertura encontrada”, indistinguível de um projeto que realmente não a tem. [FUCINI_DISCOVERY] agora nomeia cada entrada para a qual nenhum arquivo foi encontrado e o caminho onde procurou, uma vez por entrada em vez de a cada recarga; uma entrada com curinga não é relatada, pois pode estar esperando um build escrever algo.

Adicionado

• O CodeLens por função mostra agora ramos, MC/DC e uma pontuação composta, não apenas linhas e acertos — “add: 92% coberto (12/13 linhas, 52 acertos, pontuação 88%, ramos 3/4 (75%), MC/DC 2/3 (66%))”. Cada um deles é omitido numa dada função quando o ficheiro de cobertura nada tem aí a reportar — uma compilação em C puro sem dados de ramos, ou uma não instrumentada com -fcoverage-mcdc — em vez de mostrar um 0/0 enganador; a pontuação, do mesmo modo, só é mostrada ao lado de pelo menos um dos outros dois, pois com as linhas como única métrica é, por definição, o mesmo número com que a lente já começa.
• A dica do selo de origem diz há quanto tempo cada ficheiro de cobertura foi escrito, não apenas a sua data e hora — “Medido por module.info (2026-08-15 14:32 · há 3 horas), substituindo o que lcov.info (2026-08-01 09:10) dizia sobre ele.” Desce até “agora mesmo”; passados 30 dias só é mostrada a data absoluta.
• Um empate no mtime dos ficheiros de cobertura já não é silencioso. Dois relatórios que aterram no mesmo passo de compilação, ou um sistema de ficheiros cuja resolução de mtime é mais grosseira do que um segundo, podem reportar a mesma marca temporal para ficheiros que ambos medem — antes, o vencedor recorria à ordem de coverageFile.paths sem nada no ecrã que o explicasse. O canal de saída di-lo agora: [FUCINI_MERGE_TIE] nomeia ambos os ficheiros de cobertura e quantos ficheiros partilham.
• “Mostrar o que mudou desde a última execução” no menu … de uma linha de ficheiro, assim que exista uma execução anterior com que comparar — o mesmo delta por ficheiro que Compare with Last Run já calcula, apontado ao único ficheiro por que perguntou em vez de a toda a árvore. Um ficheiro em que nada se moveu di-lo claramente em vez de nada oferecer.
• Comando Tune Colour Scale: experimente cores e limiares de colorScale.* contra a vista Cobertura ao vivo antes de os fixar. Cada edição escreve diretamente na definição — a vista já se repinta a qualquer alteração de colorScale/threshold, pelo que escrever o valor é a pré-visualização — e um “Manter” ou “Repor os valores originais” final fecha o ciclo.
• Lacunas de cobertura por ficheiro no painel Problems, uma entrada por ficheiro de origem carregado abaixo de threshold.statement, atrás da nova definição fuciniCoverage.problems.enabled (desligada por predefinição — o limiar de instruções predefinido é 100). Cada entrada resume o que está por cobrir (“62% de linhas cobertas — 14 linhas não cobertas, 2 funções não cobertas”) e traz uma correção rápida que abre a extensão de chat que estiver instalada (Copilot, Claude Code, …) com um pedido para escrever um teste para a lacuna — um diagnóstico por linha inundaria o Problems num código real, por isso fica-se à granularidade do ficheiro, o nível em que um leitor pode realmente agir.

Corrigido

• O motivo de um ficheiro em falta/desajustado/verificado, na vista Cobertura, pode agora ser selecionado e copiado. Antes vivia apenas na dica nativa title da linha, que — por ser a do próprio browser — não se pode selecionar; quem quisesse colar o motivo exato num relatório de erro tinha de o redigitar à mão. Ao pairar mostra-se agora o mesmo texto num painel real, com estilo, que se pode arrastar como qualquer outro conteúdo da página. A dica de um ficheiro comum (apenas o seu caminho) não muda.
• Uma função cuja lista de parâmetros se estende por várias linhas já não é reportada falsamente como movida. O detectMismatch permitia que a linha registada de uma declaração divergisse de onde o seu nome é de facto encontrado em, no máximo, duas linhas — o suficiente para a habitual divergência entre uma linha de assinatura, uma linha de tipo de retorno e uma chaveta de abertura, mas não para uma lista de parâmetros multilinha, que pode afastar as duas arbitrariamente. void LOG_Emit(...) — sete parâmetros, um por linha — registada na sua chaveta de abertura, linha 163, era reportada como "LOG_Emit" is at line 3: a correspondência textual mais próxima, que por acaso era o nome da própria função mencionado no comentário de cabeçalho do ficheiro, longe da linha 163 e da declaração real na linha 156. A verificação aceita agora também um nome encontrado mais atrás quando cada linha entre ele e a linha registada se lê como uma única declaração ininterrupta — sem linha em branco, sem linha que termine a instrução ou o bloco anterior — o que uma lista de parâmetros faz sempre e uma função realmente movida quase nunca faz. Onde um desajuste continua a ser genuíno, a linha reportada é agora a correspondência mais próxima da registada, e não sempre a primeira encontrada no ficheiro.
• O selo de origem já não diz “+N”. Carregar o relatório de um módulo sobre uma execução mais ampla marcava o selo do ficheiro com o nome do módulo mais o número de outros ficheiros de cobertura que também o cobriam — pretendia dizer “estes tantos foram sobrepostos”, mas lia-se como “estes relatórios concordam”, e não havia forma de saber pela árvore a quais dos n se referia realmente. O selo só nomeia agora o ficheiro de cobertura cujos números estão no ecrã; a dica continua a explicar o que foi sobreposto, por qual e quando.
• O selo de origem já não empurra o nome do ficheiro ao seu lado para fora do painel. A largura do selo era fixa (flex: none), por isso, assim que uma linha ficava sem espaço, o nome do ficheiro absorvia todo o défice e era o primeiro a ser truncado, embora o selo seja o menos importante dos dois. O selo cede agora a sua própria largura antes que o nome do ficheiro perca um único carácter; a percentagem e a barra, que já têm precedência sobre o nome, não são afetadas.

Alterado

• A reexecução de um módulo substitui o que uma execução mais ampla dizia sobre ele, em vez de se lhe somar. Carregar um relatório de todo o projeto e depois, por cima, o relatório de um único módulo somava as contagens de acertos de cada ficheiro que os dois partilhavam — uma reexecução só dos testes desse módulo inflacionava números que uma execução mais ampla, agora desatualizada, já tinha reportado, em vez de os refrescar. O ficheiro de cobertura com o mtime mais recente em disco vence agora por inteiro para qualquer ficheiro que meça: instruções, ramos, declarações e os totais por ficheiro (resumos de ramos, MC/DC, funções, chamadas de funções, objetos e mutações) vêm todos só desse relatório, independentemente de onde cada caminho está em coverageFile.paths — uma reexecução de módulo vence porque é de facto mais recente, não porque calha carregar em último. Um ficheiro de cobertura que não reporta instruções nenhumas para um ficheiro — uma exportação de código-objeto do TRACE32, um relatório de mutações do Stryker carregado ao lado de um real — continua a contribuir só com o resumo que realmente traz, deixando intacto o detalhe de linhas/ramos de um relatório anterior; esse caso não muda. Isto remove também um defeito antigo em que o total por ficheiro de MC/DC (ou de funções/chamadas de funções/mutações) medido por duas execuções tinha o denominador somado juntamente com o numerador, subestimando a percentagem real. A dica do selo de origem diz agora “substituindo o que _ dizia sobre ele” em vez de “somados”.

Corrigido

• Um nome de ficheiro longo na vista Cobertura é agora truncado em vez de transbordar. Ao span do nome da linha faltava min-width: 0, a única declaração que permite que o overflow/text-overflow: ellipsis de um item flex realmente atue — sem ela, um nome longo mantinha toda a largura assim que o painel estreitava o bastante, passando por baixo do selo de origem, da percentagem e da barra que o seguem.

Adicionado

• Ordene a vista Cobertura por pontuação, não só por nome. Cada linha já traz uma pontuação WHM e uma discriminação por métrica; encontrar o pior ficheiro numa árvore grande obrigava a percorrer uma lista alfabética à procura dele. Uma lista pendente junto a Colapsar tudo / Expandir tudo oferece agora Nome do ficheiro, Pontuação composta, Linhas, Ramos e MC/DC — todos os modos exceto Nome do ficheiro intercalam pastas e ficheiros, do pior para o melhor pela percentagem própria dessa métrica, de modo que uma pasta mal testada fica exatamente como um ficheiro mal testado em vez de ser agrupada longe dele. Um ficheiro sem dados para a métrica em vista (um formato que nunca reporta ramos, digamos) ordena-se para o fundo em vez de ser lido como 0%. A escolha é escrita na nova definição fuciniCoverage.coverageView.sortBy à medida que é feita, pelo que sobrevive a uma recarga da janela em vez de voltar sempre a Nome do ficheiro.

Corrigido

• Uma assinatura de função multilinha já não é falsamente marcada como “movida”. O fnMap do Istanbul dá a uma função duas referências de linha — onde está o seu nome e onde começa o seu corpo — e o analisador preferia a linha do corpo para a verificação de desajuste que depois procura o nome no texto de origem. Para qualquer função cuja lista de parâmetros ocupa mais de duas linhas (rotina numa base de código com quebra às 100 colunas), a linha real do nome ficava demasiado longe da registada, e o ficheiro esbatia-se na vista Cobertura com um falso aviso de “já não corresponde à sua cobertura”. O analisador prefere agora a linha do próprio nome, que era o que a verificação de desajuste sempre procurou.

Adicionado

• Cada linha diz qual ficheiro de cobertura a mediu. Carregar o relatório de um módulo sobre uma execução de todo o projeto são os mesmos ficheiros medidos duas vezes, e a árvore nada dizia sobre que relatório uma linha estava a ler. Com mais do que um ficheiro carregado, cada linha passa a ostentar o nome do relatório que a mediu — o último carregado, quando foram vários — com +1 por cada um dos outros e uma dica que os nomeia. Uma fusão soma os seus acertos em vez de deixar um vencer, e a dica di-lo. Com um único ficheiro nada é desenhado, porque não haveria nada a distinguir.

Alterado

• A própria página da extensão nomeia cada definição, com o seu valor predefinido real. Vinte definições não tinham qualquer linha — o idioma, três limiares, um peso e os quinze interruptores de ações rápidas — e a linha da telemetria afirmava estar ligada por predefinição quando há já algum tempo está desligada. Um teste compara agora a página com o manifesto, valores predefinidos incluídos.

Corrigido

• A reverificação das fontes sob files.watcherExclude, acrescentada na versão anterior, obedece agora a staleWarning.enabled como o resto dessa verificação, e não a um nome de definição próprio.

Alterado

• O Explorador fica em paz. Os selos de cobertura junto aos ficheiros estão desligados por predefinição. Aquela coluna é de quem a usa — o VS Code coloca lá o M e o U do git, e só cabe um selo — e a vista Cobertura lista os mesmos ficheiros com os mesmos números, num lugar que existe para eles. explorerBadges.enabled repõe-nos tal como estavam.

Corrigido

• Uma fonte sob files.watcherExclude também é reverificada. A correspondência em direto entre um ficheiro e a sua cobertura é movida pelos gravar e por um observador do sistema de ficheiros, calado para tudo o que está excluído — sobretudo as fontes geradas em build/, onde uma marca desatualizada é mais difícil de notar. Esses ficheiros passam a ser sondados no mesmo compasso de dois segundos dos ficheiros de cobertura e relidos apenas quando realmente mudaram. Acima de duzentos, a saída di-lo em vez de gastar o compasso.

Adicionado

• O executor de testes é perguntado uma vez, não a cada execução. Uma área de trabalho com mais do que um executor reconhecido — uma configuração do jest e um go.mod, por exemplo — punha o seletor à frente de cada Run Tests with Coverage, cobrando uma tecla por uma decisão já tomada. A resposta passa a ser recordada para a área de trabalho, e a pergunta di-lo. Forget the Test Runner repõe a pergunta, e um executor recordado que a área de trabalho já não tem é ignorado em vez de executado.

Alterado

• A própria página da extensão nomeia cada comando. Catorze dos trinta e quatro tinham saído da sua tabela — documentados aqui e no guia, mas não na página que se lê antes de instalar. Agora estão todos, e um teste mantém-nos lá.

Corrigido

• Anular volta a retirar os pontos das linhas editadas. Um buffer editado desde a execução mostra pontos cinzentos nas linhas reescritas, e a cobertura retira-se delas. Anular essas edições deixava os pontos onde estavam: contava cada alteração, incluindo a que repunha o texto. Passa a recordar-se o que o buffer continha antes de alguém escrever e, assim que volta a contê-lo, os pontos saem e os números aplicam-se-lhe de novo.
• Os números de versão são verificados uns contra os outros. O manifesto, a entrada do topo do registo de alterações e a etiqueta de lançamento levam versão e compilação, os três escritos à mão, e já divergiram. O conjunto de testes compara-os agora e verifica que as entradas descem da mais recente, cada uma com uma data real.

Alterado

• Um ficheiro de cobertura removido permanece removido. Tirar um ficheiro da lista na vista Cobertura durava exatamente o que durasse a janela: sem nada configurado, a deteção recorre aos nomes conhecidos e voltava a encontrar lcov.info na manhã seguinte, e a única forma de dizer o contrário era configurar um caminho para excluir um. A decisão passa a ser recordada para a área de trabalho. Desfaz-se voltando a escolher o ficheiro ou nomeando-o em coverageFile.paths — um ficheiro que a definição nomeia nunca é retido, por isso nada pode faltar sem que alguém o tenha dito.

Corrigido

• Redesenho mais rápido de um buffer editado. A lista de linhas reescritas era recalculada a partir de todas as edições registadas em cada redesenho, pelo que um ficheiro longo editado toda a tarde pagava número de linhas vezes número de edições por uma resposta que não mudara desde a última tecla. Passa a ser calculada uma vez por tecla.

Alterado

• Uma execução de testes recorda o seu ficheiro de cobertura, tal como uma escolha à mão. O Run Tests with Coverage carregava o que a execução escrevera e depois perguntava se o devia acrescentar a coverageFile.paths. Um ficheiro escolhido à mão é lá escrito por si desde a 0.2026.56, e uma execução de testes é o mesmo ato por outra via, pelo que agora o escreve da mesma maneira. Uma só definição, coverageFile.rememberPicks, governa ambos; a linha do ficheiro na vista Cobertura é onde qualquer um deles volta a sair.

Corrigido

• Os temporizadores de fundo param quando a extensão para. O observador do ficheiro de cobertura era libertado com a janela, mas a sondagem de dois segundos por detrás dele e qualquer reverificação de fonte pendente são temporizadores simples, que nada liberta. Desativar a extensão, ou recarregar uma janela com ela desativada, deixava-os a correr e a ler uma área de trabalho que já não dizia respeito à extensão.

Adicionado

• A pré-visualização ao vivo diz o que mostra. A pré-visualização do painel de definições começa agora com Execução: coverage/lcov.info · 12 ficheiros e, quando o editor ativo mostra um ficheiro coberto pela execução, com Ficheiro ativo: src/a.c e o veredicto próprio desse ficheiro por baixo do da execução. Acompanha o editor e cada carregamento, segundo o que o formulário contém — alterações por guardar incluídas. Com o painel à frente, um clique na vista Cobertura muda a pré-visualização para esse ficheiro em vez de o abrir.
• O diálogo de escolha nomeia todos os formatos. Primeiro Todos os formatos de cobertura, depois LCOV; JSON (llvm-cov, Istanbul/nyc, coverage.py, SimpleCov, Coveralls, gcov, xccov, Stryker); XML (Cobertura, JaCoCo, Clover, OpenCover, GNATcoverage, Bullseye, SonarQube, VectorCAST, TRACE32, EMMA, UCIS/UCDB, NCover, dotCover, PIT); perfil de cobertura Go; listagem gcov e Testwell CTC++ — e .lcov, .gcov, .txt e .coveragexml já não aparecem a cinzento.

Alterado

• As dicas da barra de estado vestem a escala de cores. As barras de métricas nas dicas de execução e de ficheiro tomam as três cores de colorScale.*, escalonadas pelo limiar próprio de cada métrica quando configurado e pelos pontos da escala caso contrário; as etiquetas de veredicto mantêm as suas cores de estado fixas.
• Bandeiras desenhadas na definição de idioma. Os emoji de bandeira de 0.2026.56 aparecem no Windows como duas letras soltas. A lista nomeia agora cada idioma pelo seu próprio nome — Nederlands (nl) — com uma fila de pequenas bandeiras desenhadas por baixo que selecionam na lista.

Adicionado

• Uma escolha é lembrada. Um ficheiro escolhido com Pick Coverage File vivia apenas na janela em que foi escolhido. Agora vai sozinho para coverageFile.paths nas definições do espaço de trabalho — relativo à pasta base se estiver nela, absoluto caso contrário — para que a janela seguinte o carregue e o vigilante o recarregue. coverageFile.rememberPicks (ligado por predefinição) mantém o comportamento antigo para quem o quiser. Uma entrada absoluta nessa definição nomeia agora um ficheiro onde quer que esteja.
• Tracefiles na vista Cobertura. Acima da árvore, uma linha por tracefile carregado com o seu número de ficheiros e um botão de descarga que o retira da execução e das definições; um botão Escolher… ao lado adiciona um. Descarregar o último tracefile limpa a execução.
• Bandeiras na definição de idioma. A lista de idiomas do painel de definições mostrava códigos nus; cada entrada traz agora uma bandeira e o nome do idioma em si mesmo — 🇳🇱 Nederlands (nl), 🇯🇵 日本語 (ja), 🌐 Automático.

Corrigido

• A última linha de um ficheiro PHP já não conta como cobertura para lá do fim. O Xdebug e o PCOV registam o return implícito de fim de ficheiro na linha a seguir à última mudança de linha, pelo que o php-code-coverage escreve uma passagem na «linha 252» de um ficheiro de 251 linhas — e a verificação de discrepância chamava-lhe contradição em todos os ficheiros PHP com mudança de linha final. Uma linha para lá de uma mudança de linha final é agora admitida; uma referência mais além, ou para lá de um ficheiro sem mudança de linha final, continua a ser a contradição que era.

Adicionado

• Uma linha de período experimental em What Community Includes, na edição Community. Essa compilação nunca teve período experimental, pelo que a sua lista começa agora com Iniciar um período experimental Pro de 14 dias…, que abre a listagem Pro; a ativação da compilação Pro propõe depois afastar a compilação Community. O Community continua gratuito, decida-se o que se decidir.

Adicionado

• Show Worst-Covered Folders. A resposta ao nível da pasta a Show Worst-Covered Files: cada pasta ordenada pela cobertura de tudo o que contém, a pior primeiro, a partir do mesmo índice de que são pintados os distintivos do Explorador; uma escolha revela a pasta no Explorador. No menu da barra de estado com quickActions.worstCoveredFolders.

Adicionado

• A verificação de limiares no painel Problemas. Com compliance.diagnostics ligado, cada métrica threshold.* não atingida é um erro em Problemas, no tracefile que a falhou, atualizado a cada carregamento e por Check Coverage Thresholds, limpo quando a verificação passa. Desligado por predefinição, porque o limiar de instruções fornecido é 100.

Alterado

• A descrição de watch.enabled já não promete uma pergunta. Ainda dizia que o nível gratuito é questionado antes de recarregar — verdade até 0.2026.48, não desde então. Reescrita nas 18 línguas.

Adicionado

• Run Tests with Coverage. Reconhece vitest, jest, pytest, go, cargo, dotnet, maven, gradle, phpunit ou ctest a partir da raiz do espaço de trabalho, executa-o com cobertura ligada numa tarefa de terminal, carrega o que escreveu tenham os testes passado ou não, e propõe uma vez adicionar esse caminho a coverageFile.paths para que a partir daí o vigilante faça o carregamento. Vários executores são propostos à escolha; nenhum o envia para as receitas.

Adicionado

• A cobertura acompanha o texto num buffer editado. As edições de cada buffer aberto desde o carregamento da execução são guardadas, e cada superfície que lê números de linha da execução — a contagem ao passar o rato, a barra MC/DC, o triângulo «desde a última execução», o CodeLens, Next Uncovered — lê através delas: uma marca acompanha a sua linha e retira-se de uma linha reescrita, onde um pequeno ponto cinzento diz porquê. dirtyMarks.enabled desliga os pontos.

Adicionado

• Desde a última execução, na margem. Cada linha executada na execução anterior e não nesta traz um triângulo vermelho na margem do editor, cada linha que fez o caminho inverso um verde, cada um com uma faixa na régua de visão geral e as contagens ao passar o rato. As linhas sem alteração não mostram nada. sinceLastRun.enabled desliga-o.

Alterado

• A referência de «última execução» sobrevive a um reinício. Com history.enabled ligado, a execução mais recente do histórico ocupa esse lugar no primeiro carregamento de uma janela, pelo que uma compilação terminada antes de a janela abrir ainda mostra o que mudou — na margem e em Compare with Last Run.

Adicionado

• O veredicto sobre um ficheiro mantém-se atual após o carregamento. Um ficheiro era verificado face à sua cobertura uma vez, ao carregar o tracefile, e nunca mais: edite-o uma tarde inteira e as margens continuavam a pintar números sobre uma versão que já não existia. Agora uma gravação no editor volta a verificar esse ficheiro de imediato, e uma alteração vinda de fora do editor — um git checkout, um formatador, um gerador — volta a verificá-lo a partir do disco um instante depois. Um ficheiro que passa a contradizer a sua execução recebe a marca; um checkout que repõe a versão medida retira-a.
• A diferença exata, ao passar o rato. Onde um ficheiro já não corresponde à sua cobertura, a vista Cobertura e a dica do Explorador dizem exatamente o que o provou: a linha tal como se lê agora face ao que o relatório registou quando o tracefile guardou o texto, a linha e uma soma de verificação falhada quando guardou um resumo, cobertura para lá do fim do ficheiro, uma função que já não está onde o relatório a coloca. O mesmo detalhe vai para o canal de saída, uma linha por ficheiro, para onde leva Mostrar quais no resultado do carregamento.
• Um interruptor para os distintivos do Explorador. explorerBadges.enabled (ligado por predefinição) esconde a pontuação, ✓ e ⚠ junto a cada ficheiro coberto no Explorador, e com eles a dica por métrica. Margens, barra de estado e vista Cobertura não mudam.

Alterado

• Todos os níveis recarregam sozinhos quando o tracefile muda. Desde 2026-09-02 o nível gratuito parava numa pergunta nova cobertura detetada — carregar? enquanto as licenças pagas recarregavam em silêncio. Uma compilação termina, os números são novos, e quem ligou a vigilância já respondeu à pergunta — por isso a pergunta desapareceu em todos os níveis, e com ela o aviso que a explicava.
• Os carregamentos que o produto faz sozinho já não contam para o limite diário do nível gratuito. Um recarregamento pelo vigilante ou a descoberta no arranque não é um carregamento que alguém tenha pedido; contá-los gastaria a quota de uma instalação Community numa manhã de testes e deixaria depois uma execução antiga no ecrã sem nada que o dissesse. O limite agora mede apenas o comando e o seletor.
• Um carimbo de data/hora alterado, por si só, já não assinala um ficheiro. O aviso N ficheiro(s) alterado(s) desde esta execução vinha da mtime de cada fonte, e um git pull ou um formatador altera todas as mtime sem mudar o que foi medido. Desapareceu, com a sua marca na barra de estado. Um ficheiro só é agora dito alterado quando o seu conteúdo contradiz a execução, e a barra de estado, o resultado do carregamento e uma nova linha de saída FUCINI_MISMATCH_001 leem todos daí. staleWarning.enabled mantém o nome e descreve agora exatamente a verificação do conteúdo.
• Vigiar uma pasta sob files.watcherExclude é dito na saída. A saída da compilação é a primeira coisa que se exclui do vigilante do VS Code, após o que só a sondagem a cada 2 s repara numa nova execução. O canal de saída nomeia agora a pasta e o glob quando o vigilante arranca.

Adicionado

• Uma dica de primeira utilização para um espaço de trabalho sem nada para carregar. A monitorização está ativa por predefinição e o carregamento inicial é silencioso, por isso uma instalação nova num projeto sem ficheiro de rastreio não dizia nada. O primeiro carregamento silencioso que sai vazio diz-o agora — uma vez, para sempre — com as duas coisas que valem a pena: escolher um ficheiro de cobertura à mão, ou abrir as receitas para produzir um com a sua cadeia de ferramentas. Um carregamento lançado à mão mantém a sua própria mensagem.
• Teclas para Toggle Annotated Source e Load Coverage. Alt+A alterna o separador ativo entre a fonte e a sua vista anotada; Alt+Shift+R volta a descobrir e recarrega a cobertura (Ctrl+Alt+A / Ctrl+Alt+R no macOS). Reatribuíveis como as duas adicionadas em 0.2026.45.

Alterado

• Os caminhos que não correspondem a nada no espaço de trabalho são contados no ecrã. Um caminho do ficheiro de rastreio que não resolve para nenhum ficheiro do espaço de trabalho carrega e nunca se acende — o «funcionou mas não aparece nada» mais comum que existe — e até agora o único rasto era uma linha FUCINI_REMAP_001 no canal de saída, com a regra pathRemap que o corrigiria, por ler. O resultado do carregamento conta-os agora, com Quais? para os nomes e a regra sugerida, e Abrir a definição pathRemap para o sítio onde a colocar.
• O seletor de ficheiros do menu da barra de estado nomeia os formatos que lê. A sua descrição ainda listava os cinco formatos da primeira versão; agora diz vinte e cinco, de lcov, Cobertura e JaCoCo a gcov, llvm-cov, TRACE32 e relatórios de mutação.

Alterado

• Ambas as edições instaladas: dois botões em vez de instruções. Com o Pro e o Community presentes ao mesmo tempo, nenhum consegue ativar — definem os mesmos comandos e vistas — e a mensagem que o dizia terminava com indicações para a vista Extensões. Ambos os remédios são um comando cada, por isso agora são botões: Manter este desinstala a outra edição e propõe o recarregamento; Mostrar ambos em Extensões abre a vista Extensões exatamente nesses dois. Se a desinstalação falhar, o recarregamento é proposto na mesma — é um recarregamento que decide qual edição está ativa.
• Um limite de utilização é anunciado por inteiro uma vez, depois só na barra de estado. A primeira vez que um limite Community é atingido merece a resposta completa — os números, o plano, o desbloqueio por telemetria, a lista do que o nível inclui. A quinta vez, dez minutos depois, não. Dentro de uma sessão, novos embates no mesmo limite colocam uma linha de oito segundos na barra de estado e não interrompem nada. Introduzir uma chave recomeça, porque uma licença nova é um conjunto novo de limites.

Adicionado

• Next / Previous Uncovered têm teclas. São os dois comandos premidos vezes sem conta ao ler um ficheiro, e até agora cada pressão significava abrir a paleta de comandos e escrever o nome. Alt+N salta para o próximo intervalo não coberto e Alt+P para o anterior (Ctrl+Alt+N / Ctrl+Alt+P no macOS, onde Option escreve caracteres). Ambos valem apenas num editor de texto com foco e podem ser reatribuídos em Keyboard Shortcuts como qualquer outra predefinição.

Adicionado

• O que a Community inclui, como uma só lista. O nível gratuito limita oito ações e retém doze funcionalidades, e cada uma dessas decisões era aplicada à sua própria porta — por isso a única forma de aprender a forma do nível era esbarrar em cada parede à vez, a meio de uma tarefa. Um novo comando, What Community Includes, mostra tudo de uma vez: cada ação limitada com quanto do dia ou do mês já foi usado, cada funcionalidade retida pelo nome, e as duas formas de levantar tudo isso — um plano pago, ou o desbloqueio por telemetria.
• Oferecido onde quer que a pergunta surja. Uma entrada no menu da barra de estado, um botão no banner de licença da vista Coverage e um botão nas duas mensagens que uma instalação Community encontra numa parede — limite de utilização atingido e esta ação não está incluída. As linhas derivam do mesmo conjunto de direitos que as portas aplicam, por isso o que a lista diz é o que vai acontecer.

Alterado

• O modo de monitorização diz o que fará no nível gratuito. A entrada da barra de estado prometia a todos «recarregar automaticamente a cobertura», e na Community é uma promessa que o monitor não cumpre — repara, e pergunta. A entrada agora di-lo ali, e o comando chama-se Toggle Tracefile Watch, já que «Toggle Watch» nunca dizia o que era monitorizado. O comportamento em si não muda.

Alterado

• Um ficheiro de rastreio que não carrega diz agora porquê, e o que tentar. Cada falha produzia a mesma notificação — «no coverage could be parsed. See output.» — com a razão a um canal de distância como código e mensagem do analisador. A notificação começa agora pelo ficheiro e classifica a recusa pelo que foi: não está num formato que esta extensão leia, não está bem formado (uma compilação que ainda o escrevia é a causa habitual), bem formado mas sem nada registado (a execução não correu código instrumentado), ou não foi possível ler. As palavras do próprio analisador acompanham, vários ficheiros são contados, e o canal de saída é oferecido atrás de um botão Mostrar saída em vez de aberto à força.
• Os ficheiros que um rastreio lista mas em que não há nada para medir são agora contados no ecrã. Um cabeçalho só com declarações sempre ficou fora da vista Coverage em vez de pontuar 100% em 0 de 0 — e o seu nome era escrito no canal de saída, e em mais lado nenhum. O resultado do carregamento diz agora N ficheiro(s) sem nada para instrumentar não são mostrados, com um botão Quais? que abre o canal onde estão os nomes.

Adicionado

• NCover e JetBrains dotCover. O Cobertura do Coverlet e o OpenCover já eram lidos aqui, o que cobre a maior parte do trabalho novo em .NET e nada do tipo mais antigo. Uma compilação que ainda escreve o Coverage.xml do NCover, ou uma equipa que mede com o dotCover, tinha cobertura no disco que esta extensão não conseguia abrir. Nenhum dos formatos precisa de conversor: ambos já trazem nomes de ficheiros e números de linha.
• Um ponto excluído do NCover é descartado, não contado como não executado. excluded="true" marca código deliberadamente retirado da medição — um membro com [ExcludeFromCodeCoverage], ou um filtro do NCoverExplorer. Contá-lo como não coberto faria com que uma exclusão baixasse o número que foi feita para corrigir.
• O dotCover precisa de /ReportType=DetailedXML. O seu outro relatório XML é um resumo sem qualquer número de linha; esse relatório é reconhecido e recusado com a indicação da flag que resolve isso, em vez de falhar como formato desconhecido. O dotCover regista apenas um sim ou não por instrução, nunca uma contagem de visitas, pelo que uma instrução coberta chega como um único acerto.

Adicionado

• Testes de mutação. A cobertura diz que uma linha foi executada; uma pontuação de mutação diz que algo falhou quando essa linha foi alterada. Um conjunto de testes pode executar cada linha de um ficheiro e não detetar nenhum dos defeitos injetados, e nenhum número de cobertura o dirá. O PIT cobre Java, Kotlin e Scala; o Stryker cobre JavaScript, TypeScript, C# e Scala.
• Nunca é calculada em média com a cobertura. Misturar "esta linha correu" com "algo notou quando a mudei" não responde a nenhuma das duas, por isso não tem qualquer peso na pontuação composta e é controlada à parte através de fuciniCoverage.threshold.mutation — por defeito 0, porque uma pontuação de mutação é um objetivo a subir, não uma fasquia a ultrapassar no primeiro dia.
• Um mutante que nunca teve uma execução justa não conta em nenhuma das metades. O NON_VIABLE do PIT e o CompileError e Ignored do Stryker são mutações que a ferramenta não conseguiu criar; contá-las como não detetadas penalizaria um conjunto de testes por um defeito que nunca lhe foi oferecido.

Adicionado

• A listagem anotada .gcov. O gcov --json-format chegou com o GCC 9, e os cross-compiladores embutidos são muitas vezes bem mais antigos; até agora a resposta era instalar primeiro o lcov ou o gcovr. O contador de execução tem cinco grafias e apenas duas são números, e as anotações branch/call/function pertencem à linha vizinha em vez da própria — tudo isso agora é lido corretamente.
• As anotações de chamada tornam-se cobertura por ponto de chamada. call N returned X% é exatamente a métrica de chamadas de função adicionada em 0.2025.38, que este formato já carregava muito antes de aqui haver onde a colocar.

Adicionado

• Cobertura de código objeto — quanto do binário construído foi realmente executado. A única métrica aqui que não é medida a partir do código-fonte de todo: vem de um depurador que observa o fluxo de instruções no alvo real, sem qualquer efeito de sonda na temporização. É também a resposta honesta a "isto cobre assembly?" — o assembly escrito à mão nunca é instrumentado, e nenhuma outra métrica aqui consegue alcançá-lo.
• É um requisito, não mais um peso. A cobertura de código objeto subsume a cobertura de instruções — 100% aqui implica 100% ali, mas não o contrário — pelo que não tem qualquer peso na pontuação composta e é antes controlada por um limiar, exatamente como a DO-178C nível A exige além do MC/DC.
• A diferença é o que interessa. Uma execução com 100% de cobertura de linhas e menos de 100% de cobertura de código objeto localizou exatamente o código gerado pelo compilador que o seu código-fonte não justifica; o cartão de conformidade diz "312 bytes nunca executados, com 100% de cobertura de linhas" em vez de o esconder como "94%". O caso inverso — um binário inteiro dado como executado enquanto o seu código-fonte não o foi — é comunicado como uma contradição, não como uma pontuação baixa.

Adicionado

• Cobertura de chamadas de função — se cada ponto de chamada foi exercitado. Uma pergunta diferente da cobertura de funções: uma função invocada uma vez a partir de um dos seus três pontos de chamada está completa sob Funções e aqui completa num terço. VectorCAST, TRACE32 e Cantata reportavam todos isto enquanto este modelo não tinha onde colocar o número.
• Isto completa o VectorCAST e o TRACE32. Versões anteriores recusavam-se deliberadamente a dobrar estes dados em cobertura de ramos, porque inflacionar uma percentagem de ramos inflaciona um número que acaba numa auditoria. Ambos os formatos agora carregam o que sempre enviaram.

Alterado

• O portão de conformidade e a pontuação ponderada agora conhecem sete métricas, não seis — duas novas definições, fuciniCoverage.whmWeights.functionCalls e fuciniCoverage.threshold.functionCalls, com descrições nas 17 línguas.

Alterado

• A cobertura de funções agora conta mesmo quando a ferramenta não diz onde estão as funções. A exportação func do TRACE32, os elementos <method> autofechados do VectorCAST, e o resumo method, % do EMMA indicam todos uma contagem de funções sem nenhum sítio onde colocar um CodeLens — os três eram descartados à entrada. As declarações continuam a ser a fonte preferida onde existem; a contagem é agora usada como alternativa onde não há.

Adicionado

• UCIS e UCDB XML — VHDL e Verilog, diretamente do simulador. Dois documentos respondem por este nome, e um projeto tem aquele que o seu simulador escreveu, por isso ambos são lidos: a forma de intercâmbio padrão da Accellera <UCIS>, e o próprio ux:ucdb da Aldec, que é o que o acdb2xml realmente produz a partir do Active-HDL e do Riviera-PRO. A cobertura de instruções e ramos passa; a cobertura de toggle, FSM, asserção e funcional não é lida, e um documento que contenha apenas isso diz-o em vez de carregar vazio.
• O VHDL de código aberto já não precisava de nada aqui: o backend GCC do GHDL instrumenta com -Wc,-ftest-coverage -Wc,-fprofile-arcs, e o resultado passa por gcov, gcovr ou lcov. Esta versão é para os simuladores comerciais.

Adicionado

• EMMA XML. O Delphi não tinha absolutamente nenhuma via de entrada — nem lcov, nem Cobertura — e o DelphiCodeCoverage escreve exatamente este esquema com -xml. É também o que uma boa parte das ferramentas Java mais antigas ainda emite, pelo que um único parser abre uma linguagem e limpa um legado ao mesmo tempo.
• Adicione -xmllines e o relatório ganha contagens de acertos reais por linha, pelo que os indicadores funcionam; sem isso há apenas uma percentagem acumulada, que recebe um resumo do ficheiro e nenhum indicador em vez de um palpite. Um nome de pacote com pontos só se torna um diretório quando o ficheiro é uma fonte da família Java; num relatório do Delphi esse mesmo campo é um nome de unidade, e prefixá-lo inventaria uma pasta que ninguém tem no disco.

Adicionado

• Exportações de cobertura do TRACE32. O COVerage.EXPORT.ListModule escreve o que um depurador mediu a partir de um trace no próprio alvo — não código-fonte instrumentado, mas o fluxo de instruções que o processador realmente executou, no alvo real, sem qualquer efeito de sonda na temporização. Uma exportação carrega uma métrica de cada vez: stmt torna-se cobertura de linhas; dec/cond tornam-se cobertura de ramos; mcdc torna-se MC/DC. Carregue duas exportações da mesma execução e elas fundem-se pelo nome do módulo.
• Exportações com cobertura func, call ou object eram recusadas pelo nome em vez de carregadas vazias, indicando qual métrica o ficheiro contém — as três têm agora um lugar, respetivamente em 0.2025.37, 0.2025.38 e 0.2025.39.

Adicionado

• Listagens de perfil de execução do Testwell CTC++. O ctcpost transforma MON.sym e MON.dat numa listagem de texto de largura fixa — a ferramenta que se posiciona frente ao Bullseye nas avaliações embutidas e de segurança europeias, e a que mede a cobertura multicondição. Lida por posição de coluna em vez de dividida por espaços, porque uma descrição pode ela própria começar por um dígito.
• Multicondição não é MC/DC, e não é reportada como MC/DC. O CTC++ conta combinações de condições; o MC/DC pergunta se foi demonstrado que cada condição afeta independentemente o resultado. Colocar estes números atrás do portão do MC/DC daria a um auditor um número sob um nome que não significa isso, por isso aqui são cobertura de ramos, que é o que são.

Adicionado

• VectorCAST XML. O VectorCAST escreve um relatório Cobertura até ao doctype, e depois acrescenta atributos para o que o Cobertura comum não consegue dizer. Isso significava que estes ficheiros já carregavam aqui e pareciam completos — com o mcdcpair-coverage descartado silenciosamente à entrada, precisamente para o público que comprou uma ferramenta especificamente para o produzir. Essas contagens de pares agora sobrevivem. Alimentam o portão do MC/DC, a percentagem e a pontuação composta.
• A cobertura de chamadas de função não é deliberadamente aproximada. Dobrá-la em cobertura de ramos inflacionaria um número que acaba numa auditoria; espera que o modelo tenha um nome para ela, o que acontece em 0.2025.38.

Alterado

• O leitor de Cobertura agora carrega um dialeto: <coverage line-rate=…> é uma família, não um único formato, e qual dialeto está a ser lido viaja com a análise em vez de ser adivinhado por elemento.

Adicionado

• GNATcoverage XML — Ada, finalmente. As equipas de aviónica DO-178C e ferroviárias EN 50128 são precisamente o público para o qual foram criados a pontuação ponderada por segurança e o suporte MC/DC deste produto, e até agora não conseguiam carregar nada aqui, a menos que o seu gnatcov fosse suficientemente recente para emitir também Cobertura, que deita fora tudo o que está abaixo da linha. O gnatcov coverage --annotate=xml escreve um diretório e não um ficheiro: carregue os ficheiros *.xml por fonte — abrir o index.xml diz-lhe onde está realmente a cobertura em vez de falhar de forma obscura. Uma linha parcialmente coberta continua a ser uma linha coberta com uma decisão por cobrir: a falha aparece na cobertura de ramos e MC/DC, que é onde pertence. As regiões de isenção passam a linhas excluídas, uma obrigação indeterminada conta como não coberta e não como coberta e, com --level=stmt+mcdc, o MC/DC é contado por condição e alimenta o limiar e a pontuação composta.
• BullseyeCoverage e Visual Studio .coveragexml. O Bullseye é a ferramenta comercial de C/C++ que as equipas de sistemas embebidos e críticos para a segurança realmente possuem; execute o seu próprio covxml e carregue o resultado. A sua métrica principal é a cobertura de condição/decisão e não a de linhas, e aqui as duas mantêm-se separadas — além disso, uma sonda de resultado único é pontuada em um e não em dois, para que um switch totalmente testado não apareça como meio coberto. O .coveragexml do Visual Studio completa o .NET para equipas em MSTest e vstest em vez de Coverlet: converta primeiro o .coverage binário com dotnet-coverage convert. As linhas parcialmente cobertas sobrevivem ao percurso em ambos os casos.
• Cobertura genérica do SonarQube — e uma resposta direta sobre o Xcode. Quatro atributos em dois elementos, e importa porque quase qualquer ferramenta incapaz de emitir um dos outros formatos consegue emitir este: um projeto cuja ferramenta de cobertura esta extensão nunca conheceu passa a ter uma forma de entrar. É também o que o xcresultparser escreve, e é assim que os projetos Swift e Objective-C chegam aqui: o .xcresult não tem analisador, e a documentação agora diz porquê em vez de o deixar adivinhar — o xccov reporta percentagens, não dados por linha, e o arquivo por linha só se lê um ficheiro de cada vez, num documento que nunca nomeia o ficheiro que descreve.
• Os tracefiles em gzip carregam tal como estão. O gcov --json-format escreve .gcov.json.gz por predefinição, pelo que o formato anunciado na documentação era aquele que a maioria das pessoas não conseguia carregar. A deteção usa os magic bytes do próprio ficheiro em vez do nome, por isso um relatório comprimido que perdeu o .gz continua a funcionar — e qualquer formato suportado pode agora chegar comprimido, não apenas o do gcov.
• Swift e Objective-C, a partir do próprio relatório do Xcode. xcrun xccov view --report --json é o único documento de cobertura que uma compilação iOS ou macOS produz sem ferramentas extras. Você obtém percentuais por arquivo, contagens de execução por função e CodeLens. Ele não traz dados por linha, e o Studio não os inventa, então as margens ficam vazias neste formato — uma margem inventada é indistinguível de uma medida. Para cobertura de Swift linha a linha, use llvm-cov export -format=lcov ou slather; ambos já funcionavam.
• Coveralls JSON — escrito pelos reporters de Elixir, Ruby, Python, Rust, Go e JavaScript. É por linha, então as margens funcionam.
• Dias ativos, bloqueios de limiar e a licença a que um resumo pertence — três acréscimos ao resumo mensal de utilização, para instalações que ativaram a telemetria.

Removido

• O nome do computador já não é enviado. O hostname estava na base da telemetria desde o início — fora de qualquer verificação, enviado por quem tivesse a telemetria ligada. O nome de um computador é muitas vezes o nome de uma pessoa, um número de secretária ou o projeto de um cliente, e não respondia a nenhuma pergunta sobre utilização que o sistema operativo não respondesse melhor. Uma instalação passa a ser identificada apenas pelo seu id de instalação aleatório. Com isto, nada que o nomeie a si ou à sua máquina sai dela: nem o nome do computador, nem o nome de utilizador do sistema, nem a pasta pessoal, nem as interfaces de rede, nem os seus caminhos de ficheiros, nem o nome da pasta do projeto, nem uma etiqueta de conta com sessão iniciada. Ficam o sistema operativo, a sua versão e a sua arquitetura — que tipo de máquina, não qual.
• A telemetria passa a ser eliminada no prazo máximo de 90 dias, quando a política antes apenas dizia que era «guardada enquanto for útil», o que não é prazo nenhum.

Alterado

• Uma licença paga agora recarrega a cobertura sozinha. Monitorar um arquivo de cobertura sempre significou ser perguntado “nova cobertura detectada, carregar?” após cada compilação, em todos os níveis — uma pergunta com uma única resposta sensata, feita várias vezes por hora. Esse aviso é agora o comportamento do nível Community gratuito; uma licença paga simplesmente carrega. O Community mantém o monitoramento, a detecção e o aviso que sempre teve.
• Um arquivo que já não corresponde é indicado, com a verificação que o comprovou, em uma licença paga. A detecção não é restrita e não será: dizer a alguém que a cobertura já não descreve o arquivo dele não é algo que se venda. O Community continua recebendo a constatação, e a linha continua esmaecida. Uma licença paga acrescenta o indicador — a marca, o distintivo no Explorador e a linha, função ou soma de verificação por trás.
• A telemetria envia menos e diz a quem pertence. O resumo mensal já não leva caminhos de arquivos, o nome da pasta do seu projeto ou um rótulo de conta. A troca de recursos por telemetria agora pede um endereço de e-mail, para que quem concordou possa saber o que sua instalação envia e mandá-lo excluir a pedido.
• Três descrições de definições corrigidas. watch.enabled, staleWarning.enabled e telemetry.enabled tinham-se afastado do que o código faz — telemetry.enabled sobretudo: descrevia um envio bastante maior do que o real.

Corrigido

• O seletor de ficheiros já não esconde formatos que lê. O Pick Coverage File filtrava por info, json e xml, pelo que o coverage.out do Go e o .gcov.json.gz do gcov — ambos formatos que esta extensão lê — apareciam esbatidos precisamente na caixa de diálogo que lhe pede para escolher um.
• Uma instalação Community comum não envia mais uma página do seu código-fonte. A verificação que protegia a amostra de código anotado tratava toda instalação Community como tendo aceitado a troca de telemetria, e não apenas as que realmente aceitaram.
• Um aviso por carregamento em vez de dois — um arquivo que já não corresponde à sua cobertura quase sempre também foi editado desde a execução, e cada coisa era relatada separadamente.
• Uma desinstalação não relata mais o nome de usuário do sistema nem o diretório pessoal de alguém cuja licença o proíbe.

Adicionado

• Perfis de cobertura do Go. go test -coverprofile é a única saída de cobertura que a cadeia de ferramentas padrão do Go produz — não há um lcov de recurso como em Rust, Dart e Elixir —, pelo que um projeto em Go não tinha nada que esta extensão pudesse ler. Um perfil regista blocos em vez de linhas, e cada linha abrangida por um bloco assume a sua contagem, chaveta de fecho incluída, exatamente como go tool cover -html as realça. coverage.out passa a integrar os nomes procurados por omissão, pelo que um projeto em Go sem configuração encontra o seu perfil como um projeto em C encontra lcov.info.
• Clover XML e OpenCover XML. Clover é o que os projetos PHP têm de facto: o php-code-coverage pode emitir Cobertura, mas o Clover é o seu formato predefinido e o que quase todos os phpunit.xml configuram — a cobertura de PHP era, portanto, ilegível aqui enquanto um analisador de Cobertura esperava por uma saída que quase ninguém gera. O relator clover do Istanbul escreve o mesmo documento, pelo que um projeto Jest assim configurado também fica coberto. O OpenCover é o equivalente em .NET: C# e VB.NET já chegavam como Cobertura, que achata uma decisão na cadeia condition-coverage="50% (1/2)", de modo que qual ramo correu desaparecia antes de um analisador o ver. O OpenCover mantém uma contagem por ramo — a diferença entre saber que metade de uma ramificação está coberta e saber qual metade.
• JSON do coverage.py e do gcov/gcovr. As exportações Cobertura e lcov do coverage.py têm de chamar a uma linha com # pragma: no cover coberta ou em falta, por não terem palavra para «deliberadamente excluída» — e esta extensão tem: o mesmo sinalizador que os seus marcadores LCOV_EXCL colocam. As pragmas de um projeto em Python significam agora aqui o que significam no próprio relatório do coverage.py. Já a cobertura do GCC só chegava depois de passar por lcov ou gcovr -x: uma segunda ferramenta para converter dados que o GCC já tinha produzido. gcov --json-format --stdout e gcovr --json emitem documentos quase idênticos, e um só analisador lê agora ambos.

Corrigido

• Os comentários são lidos na linguagem em que o ficheiro está escrito. O analisador de linhas sem código foi escrito para C e aplicado a todos os ficheiros, o que estava certo enquanto todos os formatos lidos por esta extensão descreviam uma linguagem da família C. Já não está: um analisador de C que encontra # don't vê o apóstrofo abrir uma cadeia, nunca a vê fechar e conta a linha de comentário como código — um número discretamente algo errado, sem nada que o assinale. Agora é # para Python, Ruby, shell, Perl, R, Elixir e Julia; as três formas para PHP, que aceita todas; e // com /* */ para tudo o resto, o que continua a ser a predefinição para uma extensão desconhecida — #define é código, e excluí-lo seria errado no sentido inverso.

Adicionado

• Cada definição fuciniCoverage.* tem agora lugar nesse painel, não apenas as treze de conformidade. As cinquenta e cinco estão agrupadas nas mesmas secções, pela mesma ordem, que a referência de definições publicada, para que a página a partir da qual configura e a página que lê concordem sobre onde vive uma definição. Uma caixa de pesquisa filtra por nome, chave ou descrição; uma lista de atalhos desloca-o entre secções. O formulário é derivado em tempo de execução do próprio manifesto incluído na extensão — tipos, predefinições, limites, enumerações e cada palavra de texto — pelo que nada sobre uma definição está escrito duas vezes e o painel não pode divergir da extensão que edita.
• As descrições seguem o idioma que fixou. O VS Code resolve a localização de um manifesto a partir do idioma de apresentação do editor quando a extensão carrega, e não oferece forma de o substituir por extensão — pelo que definir fuciniCoverage.language para alemão num editor em inglês traduzia tudo menos as definições. Como o painel lê e resolve esses ficheiros por si, é o único sítio que pode honrar essa escolha.
• Os controlos que um esquema JSON não consegue pedir. Nada num esquema de definições marca uma cadeia como caminho, por isso a interface nativa não pode oferecer um seletor; as três definições que contêm uma pasta passam a ter um botão Procurar…. coverageFile.paths e pathRemap ganham editores de lista a sério em vez de uma caixa JSON em bruto, e cada cor colorScale uma amostra ao lado do seu valor hexadecimal.

Alterado

• Guardar escreve o que alterou, e mais nada. Com treze definições pouco importava que Guardar escrevesse as treze; com cinquenta e cinco significaria uma única edição carimbar todo o espaço de nomes num settings.json que tinha duas linhas. Só são escritas as definições cujo valor mudou de facto, e um valor igual à predefinição limpa a substituição em vez de repetir o que a extensão já traz.
• A sua chave de licença vai sempre para as definições do utilizador, e a linha di-lo. license.key está declarada com âmbito de aplicação, o que significa que o VS Code só a lê daí — escrevê-la numa área de trabalho é uma gravação que parece funcionar e não muda nada. Repor limpa agora as cinquenta e cinco chaves no âmbito escolhido em vez de treze, por isso pergunta primeiro. E uma edição feita fora do painel já não lhe custa o seu lugar: a página compara antes de repintar, pelo que Guardar já não faz cinquenta e cinco linhas voltarem ao topo.

Adicionado

• O modo de conformidade, os sete critérios de limiar e os seis pesos da pontuação composta passam a ter um único editor. Na interface de definições são treze linhas sem relação entre si e, na prática, uma só decisão: um limiar fica inerte enquanto o modo em vigor não o consultar, e um peso fica inerte enquanto não for o critério ponderado a decidir. Fucini Coverage: Configure Coverage Compliance & Thresholds..., no botão de engrenagem da barra de título da vista Coverage, junta os três, explica cada modo onde o modo é escolhido, e nomeia as formas de deixar um critério configurado sem verificar coisa nenhuma — um modo estrito sem qualquer limiar por métrica, um modo ponderado cujo limiar é 0, pesos todos a 0 — como avisos, enquanto está a olhar para eles.
• Pré-visualiza o veredicto e escreve através do VS Code. O COMPLIANT / NON-COMPLIANT que o formulário não guardado produziria face à execução carregada é calculado pelo próprio motor de conformidade da extensão e não por uma segunda cópia das regras: uma pré-visualização que pode contradizer o critério é pior do que nenhuma. As alterações passam pela API de configuração habitual para settings.json — do utilizador ou da área de trabalho, à sua escolha —, pelo que o VS Code formata o ficheiro e mantém os seus comentários; uma edição feita à mão ou noutra janela regressa ao formulário aberto, esteja ou não uma execução carregada. Não é precisa licença: o Community recebe o mesmo editor que o Pro.

Corrigido

• O botão da notificação de atualização dizia Download && Install. O E comercial duplicado é o escape dos mnemónicos, correto nos títulos do package.json e nas caixas de diálogo modais — mas os botões de ação de uma notificação recebem a sua etiqueta como texto simples, pelo que ambos os caracteres eram impressos exatamente como estavam escritos, nos 17 idiomas, a toda a gente a quem foi oferecida uma atualização.

Alterado

• A telemetria está desativada por predefinição. Era distribuída ativada, com o argumento de que o período de avaliação precisava desses dados. Esse argumento deixou de valer assim que o nível Community fez de ativar a telemetria aquilo que desbloqueia gratuitamente todas as funcionalidades Pro: uma troca só significa alguma coisa se for a pessoa a fazê-la, e uma troca que ninguém escolheu não é uma troca. Nada é enviado até a ativar, e o Community continua a funcionar de qualquer modo com o seu conjunto padrão de funcionalidades.
• A definição de telemetria diz para que serve e remete o resto. A sua descrição enumerava antes cada campo transportado por um ping, o que significava duas cópias dessa lista — uma na definição, outra na política de privacidade — que teriam de permanecer idênticas para sempre e não estavam. Agora diz o que ganha ao ativá-la e remete para a política de privacidade quanto à lista de campos, pelo que há uma lista a manter verdadeira em vez de duas.
• Instalar esta versão reabre a sua janela de avaliação, uma vez. Quem já tivesse esgotado o período experimental recebe 14 dias novos, porque esta versão altera as condições em que avaliou: um período experimental passado com a telemetria ativada por predefinição não era um período experimental do produto agora oferecido. Está deliberadamente ligado a um token de uso único e não à versão — reiniciar em cada versão significaria que o período experimental nunca termina para quem se mantém atualizado, o que não é um período experimental mas uma licença sem preço com passos extra. O token é gasto na primeira ativação e as regras habituais retomam. Uma licença paga fica intocada, já que a verificação da chave retorna antes de o período experimental sequer ser consultado, e o Community não é afetado porque essa edição não tem período experimental para reabrir.
• Uma chave de licença já não custa um questionário. As mensagens de ativação, a definição da chave de licença e a caixa de diálogo de fim do período experimental apresentavam todas a chave como algo emitido em troca de responder a perguntas. Não é: a chave é emitida automaticamente mediante pedido, e o questionário de opinião é voluntário e totalmente separado.

Corrigido

• Três locais continuavam a prometer um período experimental «até 2026-12-31». Nunca existiu tal data no produto — o período experimental dura 14 dias, contados por instalação a partir da primeira utilização. Duas versões anteriores apanharam esta afirmação nas descrições das definições e no README; sobreviveu na caixa de avaliação desta própria página, no Guia do utilizador e no README das ferramentas de licenciamento. O Guia do utilizador era o pior dos três: afirmava que a janela se aplicava «a cada instalação, em todo o mundo, de uma só vez (e não uma contagem decrescente por instalação)», precisamente o contrário, e dizia que a apresentação da cobertura é suspensa quando o período experimental termina, quando na verdade a extensão passa para o nível gratuito Community.
• Os e-mails de notificação de telemetria eram enviados do domínio errado. O cabeçalho From: era uma caixa em fucini.consulting enquanto o servidor que os envia é fucini.software — precisamente o alinhamento de que o comentário da própria definição avisa, e uma forma segura de o correio ser filtrado como spam ou rejeitado de imediato.

Alterado

• Um ficheiro que o relatório nomeia mas que não está no disco é mostrado onde pertence, a cinzento, e diz porquê. A 0.2025.25 deixou de inventar localizações para esses ficheiros, e bem, mas deixava-lhes um caminho relativo que não é sequer uma localização — por isso a árvore continuava a fazer um projeto do primeiro segmento, e as três fontes apagadas de um submódulo ficavam num app fantasma ao lado do submódulo de onde tinham vindo. A discrepância via-se, que era a intenção, mas via-se no sítio errado e nada dizia sobre o que estava mal.
• Agora aparece no projeto a partir do qual foi medido, na pasta em que o relatório o coloca — desenhado no cinzento médio do tema e em itálico em vez da cor de primeiro plano habitual. Ao passar o rato mostra o caminho que teria tido e explica que ali não há nada — muito provavelmente renomeado ou eliminado depois de o relatório ter sido gerado — e que os seus números continuam a contar. Nada é descartado e nenhum total se move: a linha é o que o relatório diz de si mesmo, e o cinzento é o que a impede de parecer uma linha que abre.
• O palpite fica dentro da vista. O caminho registado do ficheiro continua a ser exatamente o que o relatório dizia, porque tudo o resto é indexado por ele — o enriquecimento do relatório externo compara-se com ele, a telemetria torna-o relativo, a vista anotada abre-o — e dar-lhes uma localização presumida trocaria algo conhecido por algo inventado. Só a árvore junta os dois, e só para um caminho que não nomeia localização própria: um caminho absoluto que simplesmente não existe mantém o que o relatório dizia e fica a cinzento onde está.

Corrigido

• A cobertura de um submódulo fica onde o submódulo realmente está, e as suas linhas abrem. Um submódulo git constrói o seu próprio relatório junto à sua própria árvore, e o gcovr escreve nele <source>.</source> — "a pasta onde este ficheiro está" — com nomes como app/Application.cpp por baixo. Nada ancorava esse . a lado nenhum: os caminhos eram resolvidos uma só vez, depois da fusão, quando a execução já não sabia de que entrada vinha cada ficheiro, pelo que a única base restante era a raiz da área de trabalho. Tentar <workspace>/app/Application.cpp não encontrava nada, todos os caminhos ficavam relativos, e a vista de Cobertura desenhava-os como um projeto chamado app — pelo primeiro segmento de um caminho que nunca foi uma localização — cujas linhas copiavam e abriam onde ficheiro nenhum estava.
• Os caminhos passam a ser resolvidos por ficheiro de rastreio, antes da fusão. Um sourceRoot relativo é ancorado à pasta onde o seu ficheiro de rastreio está, por isso . junto ao coverage.xml de um submódulo significa esse submódulo. Se isso não encontrar as fontes, a procura sobe para cima a partir do ficheiro de rastreio — a disposição habitual do CMake escreve a cobertura vários níveis dentro de build/, e qual das duas formas um projeto usa não consta do relatório, pelo que responde o sistema de ficheiros e não a configuração. A subida para na raiz da área de trabalho: ir além deixaria um simples src/main.c resolver-se numa cópia vizinha com a mesma disposição — uma resposta errada com ar de certa. Um caminho já absoluto e existente fica como estava, por isso as execuções lcov normais não mudam.
• Um submódulo continua a ser um projeto próprio na vista de Cobertura. Os ficheiros que agora se resolvem dentro da área de trabalho teriam sido fundidos na árvore desta — as pastas do submódulo entrelaçadas com as do pai e os seus números somados ao total do pai como se uma só base de código tivesse sido medida duas vezes. Cada ficheiro regista a raiz a partir da qual foi medido e a vista agrupa por ela, pelo que um submódulo mantém cabeçalho e totais próprios mesmo estando dentro da pasta aberta. Uma execução com caminhos já absolutos não tem tal raiz e agrupa exatamente como antes.
• Um ficheiro que o relatório nomeia mas que desapareceu continua a ser reportado como em falta. Não lhe é dado um caminho plausível onde não está: um relatório que nomeia ficheiros entretanto apagados é um relatório desatualizado, e desenhá-los em localizações inventadas esconderia isso. Cada um é nomeado no canal de saída sob FUCINI_REMAP_001, com o caminho que teria tido.

Alterado

• Um lugar que desaparece diz agora porquê. Cada revogação mostrava a mesma linha — o seu lugar neste plano já não está ativo — o que se lê como uma acusação dirigida à pessoa errada. Uma subscrição de equipa reduzida abaixo dos lugares em uso liberta agora o excedente após um período de tolerância, e quem perde um lugar nada fez além de ser quem há mais tempo não o usava. Onde o servidor de licenciamento tem algo útil a dizer, a extensão di-lo: um lugar libertado para caber numa subscrição reduzida explica exatamente isso e aponta para quem gere a subscrição, com Solicitar nova chave ainda disponível — porque o caminho de volta é real: o conjunto tem espaço assim que essa pessoa libertar um lugar.
• Uma subscrição terminada não oferece botão. De uma subscrição caducada não pode ser emitida uma nova chave, pelo que a única ação daquela notificação só podia falhar — o que se lê como uma extensão avariada e não como uma subscrição terminada. Agora diz o que aconteceu e fica por aí. Qualquer motivo que esta versão não reconheça mantém a formulação geral: o servidor de licenciamento é implantado continuamente e uma extensão instalada não, pelo que encontrar um motivo desconhecido é o caso comum e não o limite — nunca mostra um identificador em bruto e nunca fica calada. Ambas as novas mensagens estão traduzidas nos dezassete idiomas.

Adicionado

• A execução já pode sair, em mais seis formatos. Até aqui só havia duas saídas: Fucini JSON, que nada além da extensão lê, e um relatório HTML, que nada lê mecanicamente. Export Coverage Report... abre um seletor de formato e grava a execução ativa como CSV por ficheiro (coberto/total/percentagem para linhas, ramos, funções, MC/DC, regiões e instanciações, os piores primeiro, com uma linha TOTAL), como CSV por função (número de execuções, se correu, ramos não cobertos no seu interior, pares MC/DC), como resumo em Markdown para colar num pull request, como ficheiro de rastreio LCOV, XML do Cobertura, SARIF, ou como emblema SVG autónomo para um README. Está na paleta de comandos, na barra de título da vista Covered Files ao lado de Generate Full HTML Report, e no menu rápido da barra de estado assim que quickActions.exportReport estiver ativo.
• Agora é um conversor, não apenas um visualizador. A extensão já lê lcov, llvm-cov JSON, Cobertura, JaCoCo, Istanbul/nyc e SimpleCov; com os escritores de LCOV e Cobertura também faz o caminho inverso. Carregue um relatório JaCoCo, ou vários relatórios fundidos numa só execução, e produza o único ficheiro de rastreio que o genhtml, o Codecov, o Coveralls e o SonarQube aceitam — ou o XML que o Jenkins, o GitLab e o Azure DevOps ingerem nativamente. Ambos voltam a passar pelos próprios analisadores da extensão, e os intervalos de linhas são expandidos linha a linha para que os LF/LH gravados coincidam com a percentagem no ecrã em vez de a aproximarem.
• Cada escritor diz o que descarta. Todos exceto os CSV perdem informação, e em silêncio: MC/DC, regiões de código e instanciações C++ não têm representação em LCOV, Cobertura ou SARIF, e o Cobertura regista quantas condições de uma linha foram cobertas, não qual. O Fucini JSON e os dois CSV continuam a ser os formatos que transportam tudo o que foi medido. Nos CSV, uma métrica que a execução não tem deixa as suas células vazias em vez de a zero — uma célula vazia diz "esta ferramenta não reportou dados de ramos", um 0 diria "nenhum ramo foi alcançado", e depois uma folha de cálculo já não os distingue. Tudo o que uma folha de cálculo executaria como fórmula — um campo começado por =, +, - ou @, ou seja qualquer caminho com âmbito npm — é citado e desarmado antes de ser escrito.
• O SARIF anota o diff; o emblema não precisa de rede. Os intervalos não cobertos são reportados ao nível note, não warning: código não coberto diz algo sobre a suite de testes, e a análise de código trata um aviso como algo que deve bloquear — o portão que bloqueia continua a ser Check Coverage Thresholds. O emblema é desenhado aqui em vez de pedido ao shields.io, pelo que funciona num repositório isolado ou local, e tira a cor da mesma colorScale das margens e da barra de estado. Na edição Community gratuita o seletor abre e ambos os CSV funcionam, com um limite de 20 exportações por dia como Export Fucini JSON; os formatos de intercâmbio são pagos, na mesma linha que esta edição sempre traçou: ler os seus próprios números é grátis, alimentar um pipeline de CI não é.

Corrigido

• Um ficheiro sem nada para instrumentar já não é apresentado como 100% coberto. Um cabeçalho apenas de declarações — protótipos, uma macro, guardas de inclusão — não tem corpos de função, pelo que o compilador não emite qualquer mapeamento de cobertura para ele, e tudo o que divide zero por zero responde 100%. Aparecia a verde na árvore, ao lado de código realmente testado. Ambos os leitores passam a tomar os totais da própria ferramenta como o relato que o ficheiro faz de si — LF/FNF/BRF em lcov, o bloco summary no JSON do llvm-cov — e um ficheiro cujos totais são todos zero fica de fora da execução em vez de ser pontuado. Os registos linha a linha por baixo desses totais são ignorados de propósito: a expansão de uma macro é atribuída à linha que a define, enquanto a contagem pertence à linha que a usa, noutro ficheiro, e essa linha emprestada era a única razão para um cabeçalho assim parecer medido. Os totais da execução também a perdem, pelo que o número principal desce um pouco e fica muito mais verdadeiro. Cada caminho descartado é nomeado no canal de saída, e um relatório em que todos os ficheiros são apenas declarações mantém-nos a todos.

Alterado

• Escolher um ficheiro de cobertura acrescenta ao que já está carregado em vez de o substituir. Uma compilação que escreve um relatório por módulo não tem um único ficheiro para fixar, e escolher o relatório do segundo módulo descarregava silenciosamente o primeiro. A caixa de diálogo aceita agora vários ficheiros de uma vez, cada escolha acrescenta-se ao conjunto e tudo o que foi escolhido é combinado numa única execução, desenhada no painel sob o nome próprio de cada projeto. A vigilância segue-os a todos e um relatório regenerado já não retira os outros do ecrã. Show Loaded Coverage Files termina com Descarregar os ficheiros escolhidos, que regressa à deteção habitual.
• O suporte tem um endereço no domínio do próprio produto: support@fucini.software. Quando a ativação não consegue concluir sozinha, o painel de licença e a mensagem do código de pedido indicavam um endereço fucini.consulting — um domínio diferente de todas as outras ligações da extensão, que se lê como outra empresa. license@fucini.software permanece igual: envia chaves, não é uma caixa para onde escrever.

Adicionado

• Cada árvore da vista Coverage diz agora a que projeto pertence. A 0.2025.19 dava a uma execução combinada um bloco com nome por projeto, mas uma execução normal continuava a desenhar uma árvore nua — por isso um espaço de trabalho reduzido à sua própria pasta abria em src, sem nada por cima a dizer qual src. Cada árvore leva agora a sua raiz: as pastas que conduzem ao projeto na cor esbatida e, depois delas, a pasta do próprio projeto a cheio. Uma árvore reduzida à pasta do espaço de trabalho continua a dizer até onde foi reduzida, e duas bases de código combinadas numa só execução nunca são lidas como uma única árvore. É um cabeçalho e não uma linha — ali não há nada para expandir, e as pastas abaixo dobram exatamente como antes. Num painel estreito, os diretórios iniciais encurtam primeiro, pelo que a pasta que realmente dá nome ao projeto é a última a desaparecer, e passar o cursor mostra o caminho inteiro.

Adicionado

• As linhas da vista Coverage têm o menu de contexto do próprio Explorador. Clicar com o botão direito num ficheiro ou pasta abria até agora o Cortar/Copiar/Colar da webview: três entradas sem nada sobre que agir. Agora abre o menu real do VS Code: Abrir, Open to the Side, Abrir com…, Reveal in Explorer View, Reveal in File Explorer, Open in Integrated Terminal, Localizar na pasta… para uma pasta e Copy Path / Copy Relative Path — com as variantes de barras ao lado no Windows, onde as duas formas diferem. O botão ⋯ e o seu menu ficam inalterados e são a última entrada do novo.

Alterado

• Uma métrica para a qual o seu ficheiro de cobertura não traz dados deixou de ser julgada. Um limiar de MC/DC sem MC/DC na compilação contava como falha — um ficheiro com 100% em todas as métricas realmente medidas ficava sob um cartão a dizer «3 de 5 cumpridas», contra uma fasquia que nada nesse ficheiro alguma vez poderia superar. As métricas sem dados são agora ignoradas em todo o lado onde se forma um veredicto: a barra de estado por ficheiro, o cartão da execução completa, o banner do código anotado e o relatório HTML. Check Coverage Thresholds continua a nomear explicitamente uma métrica em falta, que é onde isso pertence.
• Os ficheiros sem nada de mensurável ficam fora da vista Coverage. Um cabeçalho de declarações, um ficheiro só de reexportações, um módulo apenas de tipos: nenhum teste que escreva mudará o seu número, e abri-los não mostra métrica nenhuma. Em 0.2025.19 levavam um travessão; agora simplesmente não são listados, e as pastas que ficam vazias vão com eles. Uma execução em que nada é mensurável continua a listar tudo.

Corrigido

• Uma letra de unidade ainda podia encabeçar a árvore. Para cobertura cujos caminhos não ficam sob a pasta de trabalho aberta — um ficheiro combinado de outro projeto, ou uma janela sem pasta aberta — a árvore começava em W:, ou no Linux e macOS numa linha sem nome nenhum: uma linha com exatamente um filho, expansível para nada. A raiz do sistema de ficheiros nunca mais é desenhada, sejam quais forem os caminhos, e cada linha mantém o seu caminho absoluto real para o menu e o editor.

Adicionado

• Um menu de linha em cada ficheiro e pasta da vista Coverage. O botão no fim da linha copia esse caminho em qualquer das quatro formas que um editor, uma shell ou um prompt possam querer — absoluto ou relativo à área de trabalho, com os separadores do sistema ou com barras — e oferece Reveal in File Explorer e Open in Integrated Terminal, abrindo o terminal no próprio diretório do ficheiro. As entradas com barras só aparecem onde diferem da forma nativa, pelo que em Linux e macOS o menu fica com menos duas entradas. Copiar um caminho obrigava antes a encontrar o mesmo ficheiro uma segunda vez no Explorador.
• Botões para recolher e expandir tudo por cima da árvore. Recolher tudo e depois abrir a única pasta que lhe interessa é o caminho mais rápido numa árvore grande, e até agora custava um clique por pasta. O que recolher assim é recordado tal como uma pasta fechada à mão, pelo que uma recarga não o desfaz.
• Uma execução combinada que abrange mais do que um projeto desenha agora cada projeto separadamente, sob o seu próprio nome. Combinar um ficheiro de rastreio de uma segunda base de código pendurava as suas pastas na mesma árvore das da área de trabalho, pelo que src aparecia duas vezes sem dizer porquê e os diretórios dos dois projetos se misturavam por ordem alfabética. Cada projeto recebe agora o seu próprio bloco com nome, separado por um traço, com o da área de trabalho em primeiro lugar. Uma execução que abrange um único projeto mantém-se inalterada e não leva cabeçalho — não haveria nada de que a distinguir.

Corrigido

• Um ficheiro sem nada de executável era reportado como 0% coberto. Um módulo que é apenas reexportações export *, ou apenas declarações de tipos, compila para algo que nenhuma ferramenta de cobertura consegue medir — o ficheiro de rastreio não regista, portanto, uma única instrução para ele. A vista Coverage pontuava isso com 0% e colocava o ficheiro a vermelho ao lado de código que está genuinamente por testar, quando não há nada para testar; entretanto, o Explorador atribuía ao mesmo ficheiro um 100% verde, porque um total vazio lê-se como "tudo de nada está coberto". Nenhum dos números era verdadeiro e nenhum é mostrado agora: a linha do painel recebe um travessão e um contorno tracejado, com uma dica que explica porquê, e o emblema do Explorador é omitido. Uma pasta que contenha apenas ficheiros destes também fica sem pontuação. Um ficheiro que está a 0% de algo que foi de facto medido continua a mostrar 0% — o travessão significa "nada a medir", não "medido e falhado".
• As linhas de um projeto combinado apontavam para o sítio errado. Os seus caminhos eram construídos a partir da raiz da área de trabalho em vez da sua própria, pelo que, para um ficheiro fora da área de trabalho, o menu de linha copiava — e "Reveal in File Explorer" abria — um caminho onde o ficheiro nunca esteve. Agora levam a raiz de onde realmente vieram.

Alterado

• A vista Coverage já não desenha a raiz da área de trabalho. A árvore começava na raiz do sistema de ficheiros e descia por cada pasta acima do projeto — a unidade, depois o diretório que contém os seus projetos, depois o próprio projeto — antes de chegar à primeira pasta que era realmente sua. Eram vários níveis de indentação, em cada linha, a repetir o que o título da janela já dizia. Os caminhos começam agora na pasta da área de trabalho. O caminho absoluto completo continua a ser o que o menu de linha copia e o que o editor abre.

Corrigido

• As pastas que fechou na vista Coverage voltavam a abrir-se a cada recarregamento. A vigilância está ativa por predefinição, pelo que uma compilação que regenera a cobertura volta a desenhar o painel — e, como todas as pastas eram desenhadas abertas, fechar uma só durava até à compilação seguinte. Numa árvore grande, isso significava repetir o mesmo trabalho várias vezes por hora. O painel lembra-se agora das pastas que fechou e mantém-nas fechadas. Um diretório que aparece pela primeira vez numa execução posterior continua a surgir aberto, como qualquer outro: o que fica memorizado é o gesto deliberado de fechar uma pasta, não o estado predefinido.
• Desligar a telemetria não impedia o aviso de desinstalação. Esse aviso é enviado por um pequeno script autónomo que o VS Code executa quando desinstala a extensão. Não tem acesso à API do VS Code e não consegue ler as suas definições, pelo que a única coisa que lhe diz para não enviar é a ausência de um ficheiro que a extensão escreve enquanto a telemetria está ligada — e esse ficheiro nunca era removido quando desligava a telemetria. Quem a tivesse ligado e depois desligado continuaria a enviar, ao desinstalar, o nome de utilizador do sistema operativo, o nome do anfitrião e a pasta pessoal. O ficheiro é agora apagado assim que a telemetria é desligada.
• Uma renovação Pro podia comunicar sucesso para uma chave que acabara de substituir. A renovação silenciosa lia a chave configurada duas vezes: uma para decidir se renovava e outra, depois, para decidir se dizia alguma coisa. Colar uma chave nova durante uma renovação em curso fazia com que a segunda leitura visse uma chave diferente, e a mensagem «a sua subscrição Pro foi renovada» descrevia a que tinha sido substituída. A chave passa agora a ser lida uma única vez.

Alterado

• Cada módulo da extensão está agora coberto pelos seus próprios testes. Para uma ferramenta cujo trabalho é dizer-lhe até onde chegam realmente os seus testes, valia a pena fazê-lo como deve ser: 53 dos 54 ficheiros de código-fonte estão a 100% em instruções, ramos, funções e linhas, e o restante — a camada de ligação ao VS Code — a 95% das suas funções. Escrevê-los revelou as falhas acima, juntamente com cerca de vinte salvaguardas que nunca podiam ser executadas: alternativas colocadas atrás de verificações que já as tinham excluído, que pareciam redes de segurança mas não apanhavam nada. Foram removidas em vez de disfarçadas com um teste que não podia falhar.

Alterado

• O inquérito opcional espera agora que tenha realmente usado a extensão e pergunta num momento melhor. Contava dias de calendário desde a instalação, medindo há quanto tempo a instalou em vez de saber se alguma vez a viu a funcionar — uma instalação intocada durante um mês recebia o pedido de avaliar um produto que nunca lhe mostrara nada. Agora são precisos carregamentos de cobertura reais além do tempo decorrido, e deixou de aparecer enquanto o editor arranca: espera que um carregamento tenha sido bem-sucedido. Ao fim de um ano surge um terceiro e último convite, porque dois dentro do mesmo trimestre afastavam para sempre quem estivesse apenas ocupado nessa altura.
• A tradução neerlandesa deixou de ser formal. Tratava-o por «u» em todo o lado, o que soa rígido para uma ferramenta de programação e não condizia com o resto da voz do produto. Todos os textos neerlandeses usam agora «je» — reescritos frase a frase, porque a mudança arrasta consigo as formas verbais.

Alterado

• O formulário de ativação pedia um «company code» a programadores individuais. Quem compra Pro ou Pro Plus sozinho recebe um código da sua própria subscrição — não há empresa nenhuma por trás, e ser-lhe pedida sugere que se enganou no formulário. Esse campo passa a chamar-se Subscription code no Pro e no Pro Plus, e mantém-se Company code no Business e no Enterprise, onde uma equipa partilha realmente um. As indicações por baixo já eram específicas de cada plano; só a etiqueta tinha ficado genérica.

Corrigido

• O relatório HTML gerado avaliava o seu código face a 100%, independentemente dos limiares definidos. A coluna Estado testava cada métrica contra um 100 escondido, pelo que um projeto que definia os seus limites em 80 e os cumpria via um banner verde COMPLIANT mesmo por cima de uma coluna de cruzes vermelhas — para a mesma execução, na mesma página. A legenda das métricas fazia o mesmo. Ambas usam agora os seus limiares e, onde nenhum se aplica, mostram um travessão discreto em vez de inventarem um veredicto.
• O banner de conformidade afirmava mais do que tinha verificado. Dizia sempre «todos os limiares configurados cumpridos», mesmo no modo predefinido, que só avalia a pontuação ponderada — uma execução podia assim afirmar que todos os limiares tinham sido cumpridos com um deles claramente a falhar na tabela abaixo. Cada modo indica agora a regra que realmente aplicou.
• O README dizia que a extensão «funciona gratuitamente até 2026-12-31». Essa data não existe no produto. Uma versão anterior corrigiu essa afirmação nas descrições das definições mas falhou o README — a primeira coisa que se lê no Marketplace. Agora diz o que acontece de facto: 14 dias de teste desde a primeira utilização e depois o nível Community gratuito, sem qualquer data após a qual algo deixe de funcionar.

Alterado

• As duas edições já não parecem idênticas no Marketplace. O Pro e o Community são compilados a partir de uma única árvore de código e, até agora, isso incluía o ícone — pelo que as duas listagens eram a mesma imagem com legendas diferentes, lado a lado nos mesmos resultados de pesquisa. Agora cada edição tem o seu: a mesma ilustração com uma faixa colorida em baixo, turquesa para o Pro e ardósia para o Community. É a palavra que as distingue quando o ícone é mostrado em grande; numa linha de resultados a palavra é pequena demais para se ler, e é a cor que trata disso.

Corrigido

• Abrir a vista anotada já não o impede de a reabrir. O painel de código anotado é uma webview e não um editor de texto, pelo que enquanto tinha o foco a extensão não via qualquer «ficheiro atual» — e executar Open Annotated Source a partir daí respondia «abra primeiro um ficheiro com cobertura carregada», a alguém que estava a olhar precisamente para a vista anotada de um ficheiro com cobertura. Agora recorre ao ficheiro por trás do painel que tem à frente. O mesmo bloqueio também saltava silenciosamente a reverificação para a qual uma segunda execução existe: quando está configurado um relatório HTML do llvm-cov, é essa segunda execução que muda o painel para a página desse relatório — por isso, se a sua compilação de cobertura terminava depois de abrir o painel, não havia como aproveitá-la a partir do próprio painel.

Adicionado

• Uma subscrição Pro paga renova-se agora sozinha. Cada chave de ativação dura exatamente o período pago. Os planos de equipa recebem o período renovado no contacto seguinte, mas o Pro individual nunca contacta o servidor — funciona totalmente offline —, por isso nada lhe levava a renovação, e a chave de um assinante mensal teria expirado mais ou menos todos os meses por mais pontualmente que pagasse. A extensão pede agora uma chave nova discretamente, apenas nos dias em torno da sua própria validade e só quando tem o código que prova que uma subscrição a pagou. Estar offline nessa janela não custa nada: a chave continua a funcionar até expirar realmente, e a tentativa seguinte repõe-na.
• Ativar a partir do e-mail de compra é um clique. A ligação entrega o plano e o código diretamente à extensão, em vez de abrir o VS Code, procurar o comando e colar o código à mão. Pede sempre confirmação antes de usar um lugar. Introduzir o código manualmente continua a funcionar como antes — a ligação é um atalho, nunca o único caminho — e funciona também na versão Community.

Corrigido

• A descrição de uma definição afirmava que a extensão é "gratuita até 2026-12-31". Essa data não existe em lado nenhum do produto. O que acontece na realidade é um período experimental de 14 dias a contar da primeira utilização, findo o qual a extensão volta ao nível gratuito Community. É isso que passa a dizer, em todos os idiomas.
• As definições de limiar deixaram de citar a versão que alterou os seus valores predefinidos — um número de versão a meio de uma frase responde a uma pergunta que ninguém faz ao ler a descrição de uma definição.
• Várias descrições traduzidas nomeavam um comando que nenhum VS Code traduzido mostra. Referiam-se ao comando de ativação pelo nome inglês, mandando quem não trabalha em inglês procurar na paleta de comandos um texto que lá não está.

Corrigido

• Um projeto sem decisões MC/DC podia apresentar 0% de cobertura total. Algumas ferramentas comunicam uma secção MC/DC mesmo quando não há nada para medir, e isso era lido como «0% coberto» em vez de «nada a cobrir». Como a pontuação global cai para zero assim que uma métrica é zero, um projeto totalmente coberto podia mostrar 0%. Uma métrica sem nada para medir já não entra na pontuação, e a respetiva linha desaparece em vez de surgir como «0 / 0 condições cobertas».
• O estado da licença está agora traduzido nos 17 idiomas. Mantinha-se em inglês e, por aparecer dentro de frases já traduzidas, o resultado era uma linha meio traduzida na barra de estado, nas notificações e no painel de ficheiros cobertos.
• A vista Código anotado e as descrições de cobertura ao passar o rato também estão traduzidas — a tabela de detalhe da conformidade, os botões de navegação e as respetivas descrições, e o detalhe de ramos e MC/DC.

Alterado

• Uma subscrição Pro paga pode agora ser ativada com o seu próprio código. A lista de planos no pedido de chave passou a incluir uma entrada Pro, pelo que o código que acompanha uma subscrição Pro tem finalmente onde ser introduzido. As chaves Pro individuais continuam a funcionar totalmente offline e nunca contactam o servidor após a ativação.
• O ícone da barra de atividades é maior e mais visível junto aos ícones incorporados.
• Mudar para a edição Community instala-a agora a partir de fucini.software. Antes era tentado o Marketplace, onde a edição Community não está publicada, pelo que a mudança podia deixá-lo sem qualquer extensão instalada.

Alterado

• Uma subscrição expirada passa agora para o plano gratuito — quando uma chave de ativação individual terminava, a extensão continuava a pedir-lhe indefinidamente que a renovasse. Optar por não renovar é um fim normal de uma subscrição, não uma falha, pelo que a extensão passa agora, em vez disso, para o plano Community gratuito e permanente. Os planos de equipa ficam deliberadamente de fora: uma chave Pro Plus, Business ou Enterprise expirada continua a ser reportada como expirada, porque aí é um administrador que a tem de renovar, e fazer descer silenciosamente toda a empresa para o plano gratuito ocultaria isso.

Corrigido

• Desativar a telemetria é agora respeitado em todos os casos. Um caminho de código podia ignorar a verificação quando o modo interno de diagnóstico detalhado da extensão estava ativo. Esse modo está desativado em todas as compilações publicadas, pelo que nenhuma versão alguma vez se comportou desta forma, mas a verificação é agora incondicional.
• As definições aplicam-se de imediato em vez de esperarem por um recarregamento. Editar o remapeamento de caminhos, a exclusão de comentários, a filtragem por git-diff ou os totais dos ficheiros excluídos recarrega agora a cobertura de imediato — em especial o remapeamento de caminhos, pois é precisamente a definição a que recorre porque os caminhos não coincidem.
• "Unlock Full Features" e "Switch to Community" podiam parar a meio sem o indicar. Ambas são agora executadas até ao fim.
• A sua chave de ativação mantém-se associada à mesma identidade da máquina. Nalgumas configurações, essa identidade podia anteriormente ser gerada de novo entre sessões, o que invalidava uma chave já emitida.

Adicionado

• Traduções completas nos 17 idiomas distribuídos — cerca de uma centena das cadeias de interface mais recentes, incluindo as caixas de diálogo de ativação e licenciamento, o questionário de feedback opcional, o fluxo de desbloqueio Community e as notificações de atualização automática, continuavam a recorrer ao inglês em todos os pacotes não ingleses. Os 17 idiomas cobrem agora toda a interface de execução da extensão.

Alterado

• Passagem de arrumação pelos comentários do código-fonte, pela documentação dos scripts de compilação e pela lista de ficheiros de empacotamento. O conjunto de ficheiros distribuídos na extensão mantém-se inalterado; sem alterações funcionais ou de comportamento.

Corrigido

• Instalar as edições Pro e Community ao mesmo tempo podia fazer uma delas falhar no arranque — registam os mesmos comandos e a mesma vista de ficheiros de cobertura. Agora é detetado à partida: se a outra edição também estiver instalada, a ativação para de forma limpa com uma mensagem a indicar que deve desinstalar uma delas, em vez de uma falha de ativação inexplicada.

Versão de manutenção; sem alterações funcionais.

Um plano gratuito permanente, planos de equipa que partilham um pool de lugares e uma edição Community separada da extensão.

Adicionado

• Um plano Community gratuito e permanente — em vez de uma paragem abrupta quando o período de teste de 14 dias termina, a extensão passa agora para Community: todas as funcionalidades exceto MC/DC, uma amostra mensal limitada do Full HTML Report e das vistas Annotated Source persistentes, limites diários generosos num punhado de ações automatizáveis e tudo o resto sem limites.
• Desbloqueie todas as funcionalidades gratuitamente — um novo comando "Unlock Full Features" troca telemetria de utilização detalhada por uma concessão total e sem restrições, reversível a qualquer momento. Em alternativa, um questionário de feedback opcional dentro da aplicação recompensa com uma chave completa de 30 dias, sem qualquer compromisso.
• Planos de equipa: Pro Plus, Business e Enterprise — estes partilham um pool de lugares (um código da empresa mais um número de lugares) em vez de uma chave por máquina, com uma verificação periódica em segundo plano que mantém atualizada a concessão de cada lugar e assinala automaticamente um lugar revogado ou reduzido.
• Fucini Coverage Studio Community — uma publicação separada e dedicada, criada a partir do mesmo código-fonte, em que o código de teste/ativação/planos de equipa dos planos pagos está genuinamente ausente e não apenas oculto. Consulte a página de transferências.

Alterado

• A geração do Full HTML Report e as vistas Annotated Source persistentes (simples e lado a lado) passam a ser funcionalidades dos planos pagos na base Community — resta apenas a vista de alternância no local, limitada mensalmente como antes. O desbloqueio continua a conceder tudo isto.
• Um aviso de limite de utilização no plano Community passa a oferecer os dois caminhos numa única mensagem: ver os planos pagos ou desbloquear através da telemetria.

Corrigido

• A telemetria detalhada e potencialmente identificadora (nome de utilizador do sistema operativo, diretório pessoal, especificações de CPU/RAM, interfaces de rede e o conteúdo completo dos relatórios e do código-fonte) só pode agora ser enviada pelo Community ou por uma concessão gratuita condicionada à telemetria — nunca por uma licença paga Pro/Pro Plus/Business/Enterprise, independentemente das definições de telemetria locais.
• Uma instalação que já executava uma compilação anterior deixa de receber um novo período de teste apenas por ter sido atualizada — passa agora corretamente para o plano Community se o seu período de teste antigo já tinha terminado.
• A notificação de atualização, o progresso da transferência e as mensagens de erro passam a mostrar a versão simples Major.Year.Minor (a mesma que a vista Extensions do VS Code mostra) em vez de revelarem o número de compilação interno, por ex. 0.2024.6 em vez de 0.2024.6.2.

As chaves de ativação passam a poder limitar funcionalidades individuais em separado, e os administradores de licenças podem emitir manualmente uma chave à medida a partir do painel.

Adicionado

• Limites de utilização por funcionalidade — as chaves de ativação passam a poder limitar cada funcionalidade/ação de forma independente (por exemplo, exportações de relatório HTML a 1 por mês) em vez de um único limite partilhado de carregamentos de cobertura. As chaves existentes continuam a funcionar sem alterações.
• Emissão manual de chaves — os administradores de licenças podem agora emitir manualmente uma chave para um código de pedido recebido fora do questionário no editor, escolhendo exatamente que funcionalidades conceder, uma validade e limites por funcionalidade, com a chave enviada automaticamente por e-mail quando é indicado um endereço.

Corrige um erro de cache que podia esconder novas versões aos utilizadores que estão atrás de determinados proxies empresariais.

Corrigido

• Fiabilidade do feed de atualização automática — o manifesto de atualização passa a ser servido com um cabeçalho no-cache estrito, pelo que um proxy com cache entre o fucini.software e o leitor deixa de poder servir uma cópia desatualizada que esconde novas versões.

Um pequeno lançamento de manutenção: algumas correções menores de bugs e melhorias de desempenho.

Corrigido

• Correções de bugs — correções menores de bugs e melhorias de estabilidade.
• Desempenho — pequenas melhorias de desempenho no carregamento e renderização da cobertura.

As chaves de ativação agora são emitidas e aplicadas automaticamente — sem mais espera por um e-mail.

Alterado

• Ativação automatizada — pedir uma chave agora envia um breve questionário e aplica automaticamente a chave recebida às suas definições, sem troca de e-mails.
• Renovações mais rápidas — um pedido de renovação só faz perguntas sobre utilização e desejos; os seus dados de contacto de um pedido anterior são reutilizados, nunca pedidos novamente.
• Janela de avaliação fixa — o período de teste agora dura para todos até 31-12-2026, substituindo a anterior contagem decrescente de 14 dias desde a instalação.
• Fluxo de ativação localizado — o questionário de renovação e as confirmações de ativação agora estão traduzidos para os 18 idiomas suportados, tal como o resto da extensão.

A extensão agora verifica atualizações tanto no fucini.software quanto no VS Code Marketplace, oferecendo sempre a versão mais recente.

Corrigido

• Verificação de dupla fonte — agora consulta tanto o fucini.software quanto o VS Code Marketplace, oferecendo a versão mais recente.

Primeira versão pública do Fucini Coverage Studio — cobertura nativa para o VS Code que ingere ficheiros de trace de normas do setor, normaliza-os num modelo canónico único, combina execuções de forma determinística e reporta através da API Test Coverage nativa do VS Code.

Adicionado

• Ingestão multiformato — LCOV, llvm-cov JSON, Cobertura XML, JaCoCo XML, Istanbul/nyc e SimpleCov JSON, detetados automaticamente.
• Combinação determinística — vários ficheiros de trace combinados numa única execução com proveniência registada, estável independentemente da ordem de carregamento.
• UI de cobertura nativa — indicadores de linha/ramo/função, régua de visão geral e o painel Test Coverage integrado.
• Cobertura MC/DC — detalhe por decisão ao passar o cursor e um indicador de margem colorido opcional.
• Pontuação composta — uma média harmónica ponderada por SIL sobre linhas, ramos, funções, regiões, MC/DC e instanciações C++.
• Veredito de conformidade — controlo COMPLIANT / NON-COMPLIANT com os modos strict, whm, both e either.
• Remapeamento de caminhos, cobertura diferencial, emblemas do Explorer e uma barra de estado global.
• Análise no editor — CodeLens de função, informação de ramos ao passar o cursor, avisos de código morto, avisos de cobertura desatualizada e Next/Previous Uncovered.
• Vista de ficheiros cobertos, relatórios HTML, histórico e tendências, modo de vigilância e exportação Fucini JSON.