Perguntas frequentes sobre o Live Unit Testing

O Live Unit Testing funciona com as três estruturas de teste de unidade populares listadas na tabela a seguir. A versão mínima com suporte de seus adaptadores e estruturas também está listada na tabela. As estruturas de teste de unidade estão todas disponíveis no NuGet.org.

Se você tiver projetos de teste baseados em MSTest mais antigos que fazem referência a Microsoft.VisualStudio.QualityTools.UnitTestFramework e não quiser migrar para os pacotes NuGet do MSTest mais recentes, atualize para o Visual Studio 2019 ou o Visual Studio 2017.

Sim. O Live Unit Testing funciona com o .NET Core e o .NET Framework.

A janela Saída (quando a lista suspensa Live Unit Testing está selecionada) deve informar por que o Live Unit Testing não está funcionando. O Live Unit Testing pode não funcionar por um dos seguintes motivos:

• Se os pacotes NuGet referenciados pelos projetos na solução não tiverem sido restaurados, o Live Unit Testing não funcionará. Executar um build explícito da solução ou restaurar pacotes NuGet na solução antes de ativar o Live Unit Testing deve resolver esse problema.

• Se você estiver usando testes baseados em MSTest em seus projetos, remova a referência a Microsoft.VisualStudio.QualityTools.UnitTestFrameworke adicione referências aos pacotes NuGet mais recentes do MSTest, MSTest.TestAdapter (uma versão mínima de 1.1.11 é necessária) e MSTest.TestFramework (uma versão mínima de 1.1.11 é necessária). Para obter mais informações, consulte a seção "Estruturas de teste com suporte" do artigo Usar o Live Unit Testing no Visual Studio artigo.

• Pelo menos um projeto em sua solução deve ter uma referência do NuGet ou uma referência direta à estrutura de teste xUnit, NUnit ou MSTest. Esse projeto também deve fazer referência a um pacote NuGet de adaptadores de teste do Visual Studio correspondente.

Os erros de build são relatados à janela Saída quando a lista suspensa Do Live Unit Testing é selecionada. Há alguns problemas comuns causados pela configuração incorreta no assistente de instalação do que podem causar problemas de build no Live Unit Testing.

• Se a propriedade raiz do workspace for muito longa, é possível que o build falhe devido a exceções que indicam que o caminho é muito longo.

• Se a propriedade Raiz do Repositório não apontar para a raiz do repositório, o workspace será preenchido com o conjunto incorreto de arquivos.

• Para repositórios git, a propriedade Excluir arquivos geralmente evita copiar os arquivos especificados no arquivo gitignore. No entanto, é possível fazer check-in de arquivos no repositório git que são ignorados ou é possível executar ferramentas que geram arquivos automaticamente, mas eles não são gerados durante o build. Nesses casos, a opção "<Custom>" deve ser escolhida e um conjunto personalizado de regras que lista apenas as pastas de artefatos deve ser listado.

Além dos problemas descritos anteriormente, as seguintes configurações de projeto que podem não ser compiladas corretamente.

• Se as dependências do projeto forem especificadas como uma configuração de solução global e não como ProjectReferences para cada projeto, o Live Unit Testing poderá acabar criando o conjunto incorreto de projetos. Para corrigir isso, adicione referências explícitas entre projetos.

• Até que uma playlist Live Unit Testing seja escolhida, o Live Unit Testing não criará nenhum projeto. Para corrigir isso, inclua alguns testes na playlist do Live Unit Testing.

• Se você estiver usando testes baseados em MSTest em seus projetos, remova a referência a Microsoft.VisualStudio.QualityTools.UnitTestFrameworke adicione referências aos pacotes NuGet mais recentes do MSTest, MSTest.TestAdapter (uma versão mínima de 1.1.11 é necessária) e MSTest.TestFramework (uma versão mínima de 1.1.11 é necessária). Para obter mais informações, consulte estruturas de teste com suporte.

• Pelo menos um projeto em sua solução deve ter uma referência do NuGet ou uma referência direta à estrutura de teste xUnit, NUnit ou MSTest. Esse projeto também deve fazer referência a um pacote NuGet de adaptadores de teste do Visual Studio correspondente. O adaptador de teste do Visual Studio também pode ser referenciado por meio de um arquivo de .runsettings. O arquivo .runsettings deve ter uma entrada como o exemplo a seguir:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

O Live Unit Testing não pode criar os projetos do gerador de origem com instrumentação. Devido à forma como o compilador C# configura o carregamento de assembly para geradores de origem, a tentativa de criar projetos de gerador de origem com instrumentação falha ao carregar assemblies do Live Unit Testing.

Você pode definir <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> propriedade nos arquivos csproj do gerador de origem para criar esses projetos no Live Unit Testing.

O Live Unit Testing executa o build dentro de seu próprio processo por motivos de desempenho. Se esse processo de build separado estiver causando um erro, você poderá definir <UseInProcMSBuildNode>false</UseInProcMSBuildNode> para o arquivo .lutconfig para garantir que todo o build ocorra no processo do MSBuild.

• Um problema comum é que nem todos os arquivos são copiados para a pasta de teste. Talvez seja necessário adicionar alguns itens de dependência de teste de teste de unidade dinâmica aos arquivos de csproj.

• Outro problema são os tempos limite. Como o Live Unit Testing executa testes indefinidamente, ele anula automaticamente uma execução se os testes forem executados por muito tempo. Você pode aumentar o tempo limite no assistente de do projeto.

• Se vários projetos na solução fizerem referência ao pacote do adaptador de teste do NuGet, cada um deles deverá ser atualizado para a versão com suporte.

• Verifique se o msbuild .props arquivo importado do pacote do adaptador de teste também está atualizado corretamente. Verifique a versão/caminho do pacote NuGet da importação, que geralmente pode ser encontrada perto da parte superior do arquivo de projeto, como o seguinte:

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Se sua solução exigir etapas personalizadas para criar para instrumentação (Live Unit Testing) que não são necessárias para o build "regular" não instrumentado, você pode adicionar código ao seu projeto ou .targets arquivos que verificam a propriedade BuildingForLiveUnitTesting e executa etapas personalizadas de pré/pós-build. Você também pode optar por remover determinadas etapas de build (como publicar ou gerar pacotes) ou adicionar etapas de build (como copiar pré-requisitos) a um build do Live Unit Testing com base nessa propriedade de projeto. Personalizar seu build com base nessa propriedade não altera o build regular de forma alguma e afeta apenas os builds do Live Unit Testing.

Por exemplo, pode haver um destino que produz pacotes NuGet durante um build regular. Você provavelmente não deseja que os pacotes NuGet sejam gerados após cada edição feita. Portanto, você pode desabilitar esse destino no build do Live Unit Testing fazendo algo semelhante ao seguinte:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Há várias diferenças:

• A execução ou depuração de testes da janela do Gerenciador de Testes executa binários regulares, enquanto o Live Unit Testing executa binários instrumentados. Se você quiser depurar binários instrumentados, a adição de uma chamada de método Debugger.Launch em seu método de teste fará com que o depurador seja iniciado sempre que esse método for executado (inclusive quando ele for executado pelo Live Unit Testing) e você poderá anexar e depurar o binário instrumentado. No entanto, esperamos que a instrumentação seja transparente para você para a maioria dos cenários de usuário e que você não precise depurar binários instrumentados.

• O Live Unit Testing não cria um novo domínio de aplicativo para executar testes, mas os testes executados na janela do Gerenciador de Testes do criam um novo domínio de aplicativo.

• O Live Unit Testing executa testes em cada assembly de teste sequencialmente. No do Gerenciador de Testes, você pode optar por executar vários testes em paralelo.

• Gerenciador de Testes executa testes em um STA (apartamento com thread único) por padrão, enquanto o Live Unit Testing executa testes em um MTA (apartamento com vários threads). Para executar testes MSTest no STA no Live Unit Testing, decore o método de teste ou a classe que contém com o atributo <STATestMethod> ou <STATestClass> que pode ser encontrado no pacote NuGet MSTest.STAExtensions 1.0.3-beta. Para nUnit, decore o método de teste com o atributo <RequiresThread(ApartmentState.STA)> e para xUnit, com o atributo <STAFact>.

Consulte a seção "Incluir e excluir projetos de teste e métodos de teste" da Usar o Live Unit Testing no Visual Studio artigo para a configuração específica do usuário. Incluir ou excluir testes é útil quando você deseja executar um conjunto específico de testes para uma sessão de edição específica ou para manter suas próprias preferências pessoais.

Para configurações específicas da solução, você pode aplicar o atributo System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute programaticamente para excluir métodos, propriedades, classes ou estruturas de serem instrumentados pelo Live Unit Testing. Além disso, você também pode definir a propriedade <ExcludeFromCodeCoverage> para true em seu arquivo de projeto para excluir que todo o projeto seja instrumentado. O Live Unit Testing ainda executará os testes que não foram instrumentados, mas sua cobertura não será visualizada.

Você também pode verificar se Microsoft.CodeAnalysis.LiveUnitTesting.Runtime é carregado no domínio do aplicativo atual e desabilitar testes com base no motivo. Por exemplo, você pode fazer algo semelhante ao seguinte com xUnit:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

Sua solução pode ser compilada mesmo se você não estiver fazendo edições se o processo de build gerar o código-fonte que faz parte da solução em si e seus arquivos de destino de build não tiverem entradas e saídas apropriadas especificadas. Os destinos devem receber uma lista de entradas e saídas para que o MSBuild possa executar as verificações apropriadas de data up-toe determinar se um novo build é necessário.

O Live Unit Testing inicia um build sempre que detecta que os arquivos de origem foram alterados. Como o build de sua solução gera arquivos de origem, o Live Unit Testing entra em um loop de build infinito. Se, no entanto, as entradas e saídas do destino forem verificadas quando o Live Unit Testing iniciar o segundo build (depois de detectar os arquivos de origem recém-gerados do build anterior), ele sairá do loop de build porque as verificações de entradas e saídas indicam que tudo está up-to-date.

Talvez você não veja ícones no editor se os assemblies em que o Live Unit Testing está operando não forem instrumentados por nenhum motivo. Por exemplo, o Live Unit Testing não é compatível com projetos que definem <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. Nesse caso, seu processo de build precisa ser atualizado para remover essa configuração ou alterá-la para true para que o Live Unit Testing funcione. 

Você pode fazer várias coisas para coletar logs mais detalhados:

• Vá para Ferramentas>Opções> de Teste de Unidade Dinâmica e altere a opção de registro em log para detalhado. O log detalhado faz com que logs mais detalhados sejam mostrados na janela Saída.

• Defina a variável de ambiente de usuário LiveUnitTesting_BuildLog como o nome do arquivo que você deseja usar para capturar o log do MSBuild. Mensagens de log do MSBuild detalhadas de builds do Live Unit Testing podem ser recuperadas desse arquivo.

• Defina a variável de ambiente do usuário LiveUnitTesting_TestPlatformLog como 1 para capturar o log da Plataforma de Teste. As mensagens de log detalhadas da Plataforma de Teste das execuções do Live Unit Testing podem ser recuperadas do [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Crie uma variável de ambiente no nível do usuário chamada VS_UTE_DIAGNOSTICS e defina-a como 1 (ou qualquer valor) e reinicie o Visual Studio. Agora você deve ver muitos logs na guia Saída do – Testes no Visual Studio.

Não, você não deve abrir ou editar os arquivos nos diretórios de build e teste da pasta do workspace. O Live Unit Testing deve gerenciar todos os arquivos na pasta src, para mantê-los em sincronia entre o raiz do repositório e raiz do workspace.

Sim, mas você precisa ter certeza de que está habilitado. Se você estiver usando uma Unidade de Desenvolvimento, verifique se o filtro do projFS (sistema de arquivos projetado) está habilitado. Por exemplo, o comando a seguir habilita o ProjFS e o Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Consulte também

• de teste de unidade ao vivo