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 suas estruturas também é listada na tabela. As estruturas de teste de unidade estão disponíveis em NuGet.org.

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

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

A janela Saída (quando a lista suspensa do Live Unit Testing estiver selecionada) deve informar por que o Live Unit Testing não está funcionando. O Live Unit Testing poderá 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á. Fazer uma compilação explícita da solução ou restaurar os pacotes NuGet na solução antes de ativar o Live Unit Testing deverá resolver esse problema.

• Se estiver usando testes baseados no MSTest nos projetos, lembre-se de remover a referência a Microsoft.VisualStudio.QualityTools.UnitTestFramework e adicionar referências aos últimos pacotes NuGet 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, confira a seção "Estruturas de teste compatíveis" do artigo Usar o Live Unit Testing no Visual Studio.

• No mínimo, um projeto na solução deve ter uma referência ao NuGet ou uma referência direta à estrutura de teste do xUnit, NUnit ou MSTest. Esse projeto também deve referenciar um pacote NuGet de adaptadores de teste do Visual Studio correspondente.

Os erros de compilação 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 que podem causar problemas de compilação no Live Unit Testing.

• Se a propriedade Raiz do Workspace for muito longa, é possível que a compilação 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 a compilação. Nesses casos, a opção "<Personalizado>" 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 do 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 estiver usando testes baseados no MSTest nos projetos, lembre-se de remover a referência a Microsoft.VisualStudio.QualityTools.UnitTestFramework e adicione referências aos últimos pacotes NuGet 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.

• No mínimo, um projeto na solução deve ter uma referência ao NuGet ou uma referência direta à estrutura de teste do xUnit, NUnit ou MSTest. Esse projeto também deve referenciar 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 .runsettings. O arquivo .runsettings precisa ter uma entrada como o seguinte exemplo:

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

• 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 do Live Unit Testing aos arquivos 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 do projeto.

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

• Verifique também se o arquivo .props do MSBuild importado do pacote do adaptador de teste foi atualizado corretamente. Verifique a versão e o caminho da importação do pacote NuGet, que geralmente podem ser encontrados próximo à parte superior do arquivo de projeto, da seguinte forma:

    <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 a solução exigir etapas personalizadas de build para instrumentação (Live Unit Testing) que não são necessárias para o bulid não instrumentado "normal", você poderá adicionar o código ao projeto ou arquivos .targets que verificam a propriedade BuildingForLiveUnitTesting e executam etapas de pré/pós-compilação personalizadas. Também é possível optar por remover algumas etapas de build (como publicar ou gerar pacotes) ou adicionar etapas de build (como copiar pré-requisitos) a um build do Live Unit Testing baseado na propriedade desse projeto. A personalização da compilação com base nessa propriedade não altera sua compilação regular de forma alguma e afeta apenas as Compilações do Live Unit Testing.

Por exemplo, pode haver um destino que produz pacotes NuGet durante um build normal. Provavelmente, você não desejará que os pacotes NuGet sejam gerados após cada edição feita. Portanto, é possível 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 a depuração de testes na janela Gerenciador de Testes executa binários regulares, enquanto o Live Unit Testing executa binários instrumentados. Se você desejar depurar binários instrumentados, a adição de uma chamada de método Debugger.Launch ao método de teste faz com que o depurador seja iniciado sempre que o método é executado (incluindo quando ele é executado pelo Live Unit Testing). Em seguida, é possível anexar e depurar o binário instrumentado. No entanto, esperamos que a instrumentação seja transparente 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 na janela Explorador de Testes criam um novo domínio de aplicativo.

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

• O Gerenciador de Testes executa testes em um STA (Single-Threaded Apartment) por padrão, enquanto o Live Unit Testing executa testes em um MTA (Multi-Threaded Apartment). Para executar testes do MSTest no STA no Live Unit Testing, decore o método de teste ou a classe recipiente com o atributo <STATestMethod> ou <STATestClass> que pode ser encontrado no pacote NuGet MSTest.STAExtensions 1.0.3-beta. Para o NUnit, decore o método de teste com o atributo <RequiresThread(ApartmentState.STA)> e para o xUnit, com o atributo <STAFact>.

Confira a seção "Incluir e excluir projetos e métodos de teste" do artigo Usar o Live Unit Testing no Visual Studio para obter a configuração específica do usuário. É útil incluir ou excluir testes quando você deseja executar um conjunto específico de testes em uma sessão de edição específica ou para persistir 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 by Live Unit Testing. Além disso, também é possível definir a propriedade <ExcludeFromCodeCoverage> como true no arquivo de projeto para excluir todo o projeto de ser instrumentado. O Live Unit Testing ainda executará os testes que não foram instrumentados, mas sua cobertura não será visualizada.

Verifique também se Microsoft.CodeAnalysis.LiveUnitTesting.Runtime foi carregado no domínio do aplicativo atual e desabilite testes com base no motivo. Por exemplo, você pode fazer algo semelhante ao seguinte com o 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);
   }
}

A solução poderá ser compilada mesmo que você não esteja fazendo edições se o processo de build gerar um código-fonte que faz parte da própria solução e os arquivos de destino do 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 atualizadas apropriadas e determinar se um novo build é necessário.

O Live Unit Testing inicia um build sempre que detecta uma alteração nos arquivos de origem. Como o build da solução gera arquivos de origem, o Live Unit Testing em um loop infinito de build. Se, no entanto, as entradas e as 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 interromperá o loop de build, pois as verificações de entradas e saídas indicarão que tudo está atualizado.

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

É possível fazer várias coisas para coletar logs mais detalhados:

• Acesse Ferramentas>Opções>Live Unit Testing e altere a opção de log para Detalhado. O log detalhado faz com que logs mais detalhados sejam mostrados na janela de Saída.

• Defina a variável de ambiente do usuário LiveUnitTesting_BuildLog com o nome do arquivo que você deseja usar para capturar o log do MSBuild. Em seguida, as mensagens de log detalhado do MSBuild de builds do Live Unit Testing podem ser recuperadas desse arquivo.

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

• Crie uma variável de ambiente em nível de usuário chamada VS_UTE_DIAGNOSTICS e defina-a como 1 (ou qualquer valor) e reinicie o Visual Studio. Agora você verá muitos logs na guia Saída – Testes do 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 a Raiz do Repositório e a Raiz do Workspace.

Sim, mas você precisa ter certeza de que está ativado. Se estiver usando um Unidade de Desenvolvimento, certifique-se de que o filtro sistema de arquivos projetado (ProjFS) esteja ativado. Por exemplo, o comando a seguir habilita o ProjFS e o Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt, WdFilter

Confira também

• Live Unit Testing