O Visual Studio 2015 ou 2017 não descobre testes de unidade

EDIT 2016-10-19:

A pergunta original era sobre um problema específico do VS2015 CTP6 com o executor de teste do XUnit. Fica claro pelas respostas que há um problema muito mais amplo com a descoberta de teste de unidade no Visual Studio que pode ocorrer em muitas situações diferentes. Limpei minha pergunta para refletir isso.

Também incluí um script em minha própria resposta que ainda uso até hoje para resolver problemas semelhantes quando eles aparecem.

Muitas outras respostas também se mostraram úteis para entender melhor os meandros do corredor de teste do VS. Compreendo que as pessoas ainda estejam compartilhando suas soluções!

Pergunta original 2015-04-10:

Desde ontem, meu Visual Studio Test Explorer não descobrirá testes para nenhum dos meus projetos. Também não mostra a barra de carregamento verde após a construção.

Quando vou ao Visual Studio Test Explorer e clico em "Executar Tudo", ou quando clico com o botão direito do mouse em qualquer método de teste e seleciono "Executar Testes", recebo o seguinte na minha janela de saída:

Could not load file or assembly 'Microsoft.VisualStudio.Web.ProjectSystem, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Estou executando o Visual Studio 2015 CTP 6 no Windows 10 Pro Technical Preview, construção 10041. A versão do .NET Framework não parece importar - acontece na 4.0, 4.5.2e 4.6.

Tentei com as seguintes estruturas de teste e todas elas apresentam o mesmo comportamento:

• Microsoft.VisualStudio.QualityTools.UnitTestFramework v14.0.22609.0
• xunit v2.1.0-beta1-build2945 com xunit.runner.visualstudio v2.1.0-beta1-build1051
• NUnit v2.6.4 com NUnitTestAdapter v2.0.0

Encontrei um problema no GitHub (xunit) que parecia ser semelhante: Não é possível obter os testes descobertos # 295 , com este comentário da equipe do xunit:

Esteja ciente de que o Visual Studio 2015 CTP 5 foi relatado como quebrado por muitas pessoas com testes de unidade em geral (não apenas xUnit.net), portanto, não espere que isso funcione.

Além disso, verifique se você limpou o cache do corredor do Visual Studio. Se ele for corrompido, o Visual Studio se comportará permanentemente até que seja excluído. Para limpar o cache, desligue todas as instâncias do Visual Studio e exclua a pasta% TEMP% \ VisualStudioTestExplorerExtensions (honestamente, provavelmente não faria mal excluir tudo em% TEMP% que pode ser excluído).

Eu tentei a sugestão deles para excluir a pasta %TEMP%\VisualStudioTestExplorerExtensions. Infelizmente isso não resolveu o problema.

Notei que o ReSharper é capaz de descobrir alguns testes. Funciona apenas para os testes VS e NUnit, não para xunit.

É necessário limpar algum tipo de pasta temporária ou de cache, mas sei que o Visual Studio possui muitos deles e nem todos podem ser excluídos sem efeitos colaterais indesejados.

Para minha surpresa, limpar os arquivos temporários localizados no %TEMP%diretório resolveu o problema para mim.

Nota: Esse caminho geralmente é de C:\Users\(yourusername)\AppData\Local\Temp

Como o @ Warren-P incluído, você pode navegar para a pasta temp %temp%inserindo %temp%o menu Iniciar ou iniciar o "File Explorer" e entrar na barra de endereço.

Pode ser que seu código seja compilado com x64, portanto, é necessário ativar a Arquitetura do Processador Padrão como X64.

Test > Test Settings > Default Processor Architecture > X64

• Verifique se o NUnit Test Adapter 2/3 está instalado no VisualStudio.
  (Tools>Extensions and Updates )

• Verifique se a arquitetura correta do processador foi escolhida:
  (Test>Test Settings>Default Processor Architecture)

EDIT 19/10/2016 (script do PowerShell)

Esse problema ainda retorna de vez em quando. Eu escrevi um pequeno snippet do PowerShell para automatizar a limpeza dos arquivos / pasta temporária / arquivos relevantes para mim. Estou compartilhando aqui para futuros leitores:

@(
"$env:TEMP"
"$env:LOCALAPPDATA\Microsoft\UnitTest"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ComponentModelCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\Designer\ShadowCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ImageLibrary\cache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio Services\6.0\Cache"
"$env:LOCALAPPDATA\Microsoft\WebsiteCache"
"$env:LOCALAPPDATA\NuGet\Cache"
) |% { Remove-Item -Path $_ -Recurse -Force }

Certifique-se de fechar o Visual Studio antecipadamente e provavelmente é uma boa ideia reiniciar posteriormente.

A exclusão da pasta TEMP pode não ser necessária e, em alguns casos, até indesejável; portanto, recomendo tentar sem limpar a pasta TEMP primeiro. Apenas omita o "$env:TEMP".

Resposta original 2015-04-12

O problema foi "resolvido" após uma limpeza completa das pastas temporárias / cache relacionadas ao Visual Studio.

Como não tive tempo de analisar tudo um por um e depois testar no meio, infelizmente não sei qual realmente causou o problema.

Estas são as etapas exatas que eu tomei:

1. Visual Studio fechado
2. Utilizou o CCleaner para limpar temparquivos / pastas do sistema e do navegador

3. Limpou / excluiu manualmente os seguintes arquivos / pastas:

   • %USERPROFILE%\AppData\Local\assembly
   • %USERPROFILE%\AppData\Local\Microsoft\UnitTest
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\Designer\ShadowCache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ImageLibrary\cache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio Services\6.0\Cache
   • %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
   • %USERPROFILE%\AppData\Local\NuGet\Cache
   • %USERPROFILE%\AppData\Local\Temp

Uma razão para esse problema é que sua classe de teste não é pública. O MSTest apenas descobre testes de classes públicas.

No Visual Studio 2015 (Atualização 3), se você deseja anexar os testes no test explorer, instale o NUnit Test Adapter. Faça o download do adaptador na guia Ferramentas-> Extensão e atualizações-> Online (você deve procurar o adaptador ) -> Download . Ao reiniciar o Visual Studio, você pode ver a alteração na estrutura de teste.

Não tenho uma resposta completa para isso, mas determinei algumas coisas jogando com um projeto de teste:

1. O xunit.runner.aspnet : 2.0.0-aspnet-beta4que parece fazer parte do lançamento oficial do beta4 aspnet5 não funciona no Visual Studio.
2. Em vez disso, o uso de pacotes "xunit": "2.1.0-*"e "xunit-runner.dnx": "2.1.0-*"funciona no Visual Studio.
3. Para que o VS descubra os testes, seu projeto DEVE ter um comando ÚNICO chamado "teste" que execute "xunit.runner.dnx". Adicionar comandos adicionais pode danificá-lo.
4. Se a janela do Test Explorer ainda estiver vazia, REMOVA o comando "test" do seu projeto, recrie a solução e adicione o comando "test" novamente ao projeto.json.
5. Limpar todos os seus caches de acordo com a sugestão de @ Fred-Kleuver pode ajudar, mas eu não fiz todas as etapas isoladamente, por isso não tenho certeza.

Isso é atual conforme o CTP 6 do VS 2015, usando as versões beta4, não os diários.

Eu tive um exemplo em que alguns testes não seriam selecionados porque eu os fiz asyncda seguinte maneira:

public async void This_IsMy_UnitTest()

O problema foi que eu esqueci de fazê-los retornar um Taske não voidquando fiz a troca. Alguém poderia pensar que isso causaria um erro ou falha no teste, mas não. Os testes de unidade nessa classe foram totalmente ignorados e agiram como se não existissem.

Não foi depois das 3 limpezas e compilações + reinicialização VS.NETque eu vi o teste ser executado e falhar, indicando que eu esqueci de adicionar o Tasktipo de retorno:

public async Task This_IsMy_UnitTest()

Após a atualização, os testes de unidade foram encontrados e funcionaram corretamente. Pode ser um caso delicado, mas ter asynctestes para uso awaitinterno, mas não ter a assinatura correta, pode causar o mesmo problema e não é a primeira vez que o faço.

Vá para o gerenciador de pacotes Nuget e faça o download do Nunit Adapter da seguinte maneira.

Eu tinha o mesmo pronome, mas a pasta "% TEMP% \ VisualStudioTestExplorerExtensions" não existia na minha máquina, então, ao ler as postagens, tive a ideia de criá-la e funcionar. O explorador de testes agora pode mostrar todos os meus testes. Obrigado.

Basta reiniciar o Visual Studio e, no Gerenciador de Testes, "Executar Tudo" ... Todos os meus testes são descobertos.

No meu caso (Visual Studio Enterprise 2015 14.0.25425.01, Atualização 3, Resharper 2016.2), só precisava fazer uma solução limpa no menu Build. A reconstrução da solução faz com que o explorador de testes "acorde" e encontre todos os testes novamente.

A solução no meu caso foi apenas instalar a extensão NUnit 3 Test Adapter no meu Visual Studio 2015.

No meu caso, o problema estava "entre a cadeira e o teclado". Eu havia mudado para uma configuração no Gerenciador de Configurações que não incluía meus projetos de teste de unidade na compilação. Voltando a uma configuração (por exemplo, Debug) que inclui todos os projetos corrigidos.

No meu caso, o MSTest no VS 2015 estava ignorando testes com nomes de teste (ou seja, método) com mais de 174 caracteres. Encurtar o nome permitiu que o teste fosse visível. Isso foi determinado através de adivinhação e verificação, manipulando o nome do teste.

Isso provavelmente não ajudará a maioria das pessoas, mas alguém inexperiente no teste de unidade havia escrito um método de teste que retornou em boolvez de void:

[TestMethod]
public bool TestSomething()

Alterar o tipo de retorno para voidcorrigir o problema.

Verifique se você possui o xunit.runner.visualstudiopacote em seu projeto de teste packages.config e também se foi restaurado corretamente.

Eu sei que esse não foi o caso da pergunta original, mas poderia economizar tempo para alguém como eu.

Gostaria apenas de acrescentar que encontrei uma solução totalmente diferente das acima.

Eu havia declarado minha classe de teste como abaixo:

[TestClass]
class ClassificationTests
{
   //unit tests
}

Assim que adicionei o publicmodificador à classe, ele funcionou como esperado!

Se você estiver direcionando o .NET Standard ou o .NET Core, precisará usar o pacote NuGet para o NUnit Test Adapter e não a extensão .

É recomendável instalar o adaptador do NuGet se você estiver testando projetos .NET Core ou .NET Standard. O adaptador VSIX não suporta e não suporta o .NET Core porque os pacotes VSIX não podem direcionar várias plataformas.

Fonte: NUnit GitHub Wiki

.

Verifique também as perguntas frequentes lá:

Meus testes não estão aparecendo no Visual Studio 2017?

• Você está usando o pacote NuGet?
• Você está usando a versão 3.8.0 ou mais recente do pacote NuGet?
• Seus testes têm como alvo o .NET Core ou o .NET Framework completo? (Veja acima)
• Você adicionou uma referência de pacote ao Microsoft.NET.Test.Sdk?
• Você reiniciou o Visual Studio? Ainda é um pouco temperamental.

Fonte: NUnit GitHub Wiki

Isso aconteceu comigo porque meu projeto de teste continha um app.config. Ele foi adicionado automaticamente pelos pacotes NuGet para redirecionamento de assembly, mas meus testes pareciam funcionar bem sem ele.

Consulte: https://developercommunity.visualstudio.com/comments/42858/view.html .

Eu tive o mesmo problema. Acabei de limpar e reconstruir o projeto e pude ver os testes que estavam faltando.

Aparecendo para compartilhar minha solução. Eu estava no Windows 10, Visual Studio 2015, NUnit 3.5, NUnit Test Adapter 3.6 (via NuGet, não a extensão VISX) e nenhum dos meus testes estava sendo descoberto. Meu problema era que, no projeto de testes da minha solução, de alguma forma um atalho para a minha pasta "Documentos" havia sido criado dentro da pasta do projeto. Suponho que o adaptador de teste estava vendo o atalho e desligando, tentando descobrir o que fazer com ele, resultando na falha na exibição dos testes de unidade.

A exclusão do arquivo \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFold‌ erCache.xml resolveu o problema para mim.

Este tópico está um pouco desatualizado, mas minha solução para o status de Teste ausente no VS2015:

O status da tarefa aparece apenas na configuração de compilação Debug. Obviamente, isso também torna impossível depurar seu teste através do test-explorer.

Também fui mordido por esse maravilhoso recurso e nada descrito aqui funcionou para mim. Não foi até que eu verifiquei a saída da compilação e notei que os projetos pertinentes não estavam sendo construídos. Uma visita ao gerente de configuração confirmou minhas suspeitas.

O Visual Studio 2015 felizmente me permitiu adicionar novos projetos, mas decidiu que não valia a pena construí-los. Depois que adicionei os projetos à compilação, ele começou a funcionar bem.

Eu o resolvi alterando o X64 para: Clique com o botão direito do mouse em projeto -> Propriedades -> Compilar -> Destino da plataforma -> Qualquer CPU

De alguma forma, meu projeto foi definido para compilar como uma Biblioteca Estática (.lib) . Depois de alterar isso para uma Biblioteca dinâmica (.dll) , os testes foram descobertos corretamente pelo Visual Studio 2012.

My Unit Test Project ->
Properties ->
Configuration Properties ->
General ->
Configuration Type

Foi tão fácil para mim corrigir o problema como:

• Selecione seu projeto de teste de unidade
• Clique no botão 'Mostrar todos os arquivos' no Gerenciador de Soluções e novos arquivos temporários apareceram na árvore de arquivos do Gerenciador de Soluções em 'obj \ x86 \ Debug'.
• Exclua esses arquivos temporários e reconstrua o projeto.
• Tentou novamente executar testes e funcionou!

Nós tivemos o mesmo problema. Temos uma grande solução do VS 2015 com vários projetos de C # e ainda mais projetos de teste.

A descoberta de teste do resharper funcionou muito bem, mas o VS Test Explorer falhou miseravelmente.

Acontece que os projetos não tinham a mesma versão do MsTest TestFramework e TestAdapter, e que às vezes usavam o NuGets e outras vezes boas referências antigas, e isso aparentemente não é suportado (tanto por um IDE tão caro).

A remoção de todas as referências do Microsoft.VisualStudio.Test * e a adição / atualização dos dois NuTets do MSTest corrigiram o problema.

Resolvi esse problema percebendo que o Target Framework para o meu projeto de teste era diferente do projeto em teste. Sim, eu causei esse problema alterando a estrutura de destino do padrão (Projeto> Propriedades> Aplicativo), mas falhei nisso para o projeto de teste, que foi criado várias semanas depois. A incompatibilidade não causou um erro do compilador, mas resultou em um aviso na janela Lista de Erros . Depois de selecionar a opção para exibir avisos, a solução ficou óbvia.