Perguntas frequentes sobre testes de unidade ao vivo

O Teste de Unidade em Tempo Real funciona com as três estruturas populares de teste de unidade listadas na tabela a seguir. A versão mínima suportada de seus adaptadores e estruturas também está listada na tabela. As estruturas de teste de unidade estão todas disponíveis em NuGet.org.

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

Sim. O Teste de Unidade ao Vivo funciona com o .NET Core e o .NET Framework.

A janela Saída (quando a lista suspensa Teste de unidade ao vivo é selecionada) deve informar por que o teste de unidade ao vivo não está funcionando. O teste de unidade ao vivo 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 Teste de Unidade ao Vivo não funcionará. Executar uma compilação explícita da solução ou restaurar pacotes NuGet na solução antes de ativar o Teste de unidade ao vivo deve resolver esse problema.

• Se você estiver usando testes baseados no MSTest em seus projetos, certifique-se de remover a referência a Microsoft.VisualStudio.QualityTools.UnitTestFrameworke adicionar referências aos pacotes NuGet MSTest mais recentes, 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 suportadas" do artigo Use Live Unit Testing in Visual Studio.

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

Os erros de compilação são relatados na janela Saída quando a lista suspensa Teste de unidade ao vivo é selecionada. Há alguns problemas comuns causados por configuração incorreta no assistente de configuração do que podem causar problemas de compilação no Live Unit Testing.

• Se a propriedade Workspace Root for muito longa, é possível que a compilação falhe devido a exceções que indicam que o caminho é muito longo.

• Se a propriedade Repository Root não apontar para a raiz do repositório, o espaço de trabalho será preenchido com o conjunto errado 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 estes não são gerados durante a compilação. Nesses casos, a opção "<Custom>" deve ser escolhida e um conjunto personalizado de regras que listam 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 Teste de Unidade em Tempo Real pode acabar criando o conjunto incorreto de projetos. Para corrigir isso, adicione referências explícitas entre projetos.

• Até que uma lista de reprodução Teste de Unidade ao Vivo seja escolhida, o Teste de Unidade ao Vivo não criará nenhum projeto. Para corrigir isso, inclua alguns testes na lista de reprodução Teste de unidade ao vivo.

• Se você estiver usando testes baseados no MSTest em seus projetos, certifique-se de remover a referência a Microsoft.VisualStudio.QualityTools.UnitTestFrameworke adicionar referências aos pacotes NuGet MSTest mais recentes, 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 suportadas.

• Pelo menos um projeto em sua solução deve ter uma referência NuGet ou referência direta à estrutura de teste xUnit, NUnit ou MSTest. Este 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 de .runsettings deve ter uma entrada como o exemplo a seguir:

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

O Teste de Unidade em Tempo Real não pode construir os projetos do gerador de origem com instrumentação. Devido à forma como o compilador C# configura o carregamento de montagem para geradores de origem, a tentativa de construir projetos de gerador de código-fonte com instrumentação falha ao carregar montagens de teste de unidade ao vivo.

Você pode definir <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> propriedade nos arquivos csproj do gerador de código-fonte, para fazer com que esses projetos sejam compilados no Live Unit Testing.

O Live Unit Testing executa a compilação dentro de seu próprio processo por motivos de desempenho. Se esse processo de compilação separado estiver causando um erro, você pode definir <UseInProcMSBuildNode>false</UseInProcMSBuildNode> para o arquivo de .lutconfig para garantir que toda a compilação aconteça no processo 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 unidade ao vivo aos arquivos csproj.

• Outra questão são os tempos limites. Como o Live Unit Testing executa testes indefinidamente, ele aborta 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 NuGet, cada um deles deverá ser atualizado para a versão suportada.

• Verifique se o arquivo de MSBuild .props 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 encontrado na 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 requer etapas personalizadas para criar para instrumentação (Live Unit Testing) que não são necessárias para a compilação não instrumentada "regular", então você pode adicionar código ao seu projeto ou arquivos .targets que verifica a propriedade BuildingForLiveUnitTesting e executa etapas personalizadas pré/pós-compilação. Você também pode optar por remover determinadas etapas de compilação (como publicar ou gerar pacotes) ou adicionar etapas de compilação (como copiar pré-requisitos) a uma compilação de Teste de Unidade em Tempo Real com base nessa propriedade de projeto. Personalizar sua compilação com base nessa propriedade não altera sua compilação regular de forma alguma, e afeta apenas as compilações de teste de unidade em tempo real.

Por exemplo, pode haver um destino que produz pacotes NuGet durante uma compilação regular. Você provavelmente não quer que os pacotes NuGet sejam gerados após cada edição feita. Portanto, você pode desativar esse destino na compilação de teste de unidade ao vivo fazendo algo como o seguinte:

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

Existem várias diferenças:

• A execução ou depuração de testes da janela Test Explorer executa binários regulares, enquanto o Live Unit Testing executa binários instrumentados. Se você quiser depurar binários instrumentados, adicionar 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 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ê na 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 a partir da janela Test Explorer criam um novo domínio de aplicativo.

• O Teste de Unidade em Tempo Real executa testes em cada montagem de teste sequencialmente. No Test Explorer, você pode optar por executar vários testes em paralelo.

• Test Explorer executa testes em um apartamento de thread único (STA) por padrão, enquanto o Live Unit Testing executa testes em um apartamento multithreaded (MTA). Para executar testes MSTest em STA em Teste de Unidade em Tempo Real, 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" do artigo Usar teste de unidade ao vivo no Visual Studio para obter 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 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 Teste de Unidade em Tempo Real. Além disso, você também pode definir a propriedade <ExcludeFromCodeCoverage> para true em seu arquivo de projeto para excluir todo o projeto de ser instrumentado. O Teste de Unidade ao Vivo 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 está carregado no domínio do aplicativo atual e desabilitar testes com base no motivo. Por exemplo, você pode fazer algo como o 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 criar mesmo se você não estiver fazendo edições se o processo de compilação gerar código-fonte que faz parte da própria solução e seus arquivos de destino de compilação 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 de data de up-toapropriadas e determinar se uma nova compilação é necessária.

O Teste de Unidade em Tempo Real inicia uma compilação sempre que deteta que os arquivos de origem foram alterados. Como a compilação da sua solução gera arquivos de origem, o Live Unit Testing entra em um loop de compilação infinito. Se, no entanto, as entradas e saídas do destino forem verificadas quando o Live Unit Testing iniciar a segunda compilação (depois de detetar os arquivos de origem recém-gerados da compilação anterior), ele sai do loop de compilação porque as verificações de entradas e saídas indicam que tudo está up-todata.

Talvez você não veja ícones no editor se os assemblies nos quais o Live Unit Testing está operando não forem instrumentados por qualquer motivo. Por exemplo, o Live Unit Testing não é compatível com projetos que definem <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. Nesse caso, seu processo de compilação 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 em Tempo Real e altere a opção de registro para Detalhado . O registro detalhado faz com que logs mais detalhados sejam mostrados na janela de saída do.

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

• Defina a variável de ambiente de usuário LiveUnitTesting_TestPlatformLog como 1 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 de nível de 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 Output - Tests no Visual Studio.

Não, você não deve abrir ou editar os arquivos nos diretórios de compilação e teste da pasta do espaço de trabalho. O Live Unit Testing deve gerenciar todos os arquivos na pasta src do, para mantê-los sincronizados entre o Repository Root e Workspace Root.

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

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Ver também

• Teste de unidade ao vivo