Tenho lutado com o VS 2017 desde que o instalei. Agora parece que os testes de unidade só serão executados na linha de comando "dotnet test".

Meu projeto é o .NET Core 1.1.1. Eu tenho o SDK e a atualização da estrutura para 1.1.1 instalada.

Eu tentei o exemplo no MSDN ( https://msdn.microsoft.com/en-us/library/ms182532.aspx ), que também falha exatamente da mesma maneira.

Todos os pacotes NuGet para os testes e o projeto principal são atuais. E o projeto de teste e o projeto principal são construídos sem erros. Os testes são executados com sucesso na linha de comando.

Alguém já fez testes de unidade para executar no VS 2017, se sim, como?

Obrigado John

Atualização - Estender

Aqui está um exemplo de um projeto de teste simples que não está funcionando no GitHub . Este é um exemplo com o xUnit, mas eu tentei o NUnit e o visual studio integrados nos testes da MS. Não importa que teste ou que mudanças eu faça, não consigo que o testador do VS encontre nenhum teste.

O que eu tentei

• Excluindo arquivos de cache de teste do VS DEL %TEMP%\VisualStudioTestExplorerExtensions
• Reiniciando o VS
• Fechando / abrindo o explorador de teste
• para xUnit instalado Microsoft.DotNet.InternalAbstractions( consulte a publicação do SO )
• para NUnit, verifique se o adaptador está instalado e a mesma versão (3) do pacote NUnit
• test -> test settings -> default processor architecture está definido como x86

A pergunta
Alguém pode fornecer um exemplo de trabalho de uma solução .Net Core 1.1.0 no VS2017 (arquivos de projeto .csproj) em que o VS test explorer encontra com êxito os testes de unidade OU me mostra o problema no exemplo fornecido.

No meu caso, simplesmente tive que atualizar meus adaptadores de teste e estrutura de teste. Feito.

Exemplo usando o Gerenciador de Pacotes NuGet:

Isso funcionou para mim (não sei se é o resultado de alterações nos espaços de trabalho que corromperam algo):

Excluindo arquivos de cache de teste do VS em% TEMP% \ VisualStudioTestExplorerExtensions e reinicie o VS2017.

A API para adaptadores de teste para .NET Core foi alterada com o lançamento do Visual Studio 2017 e a mudança do project.jsonformato para o csprojformato. Isso tornou obsoletos os dotnet-test-*adaptadores existentes dotnet-test-nunit.

Os adaptadores foram atualizados, mas a maneira como você configura e executa testes no Visual Studio ou na linha de comando dotnet testrequer referências diferentes em seus projetos de teste. Cuidado com qualquer documentação que você achar que pacotes de referência no dotnet-test-*formato porque estão desatualizados.

Primeiro, seu projeto de teste deve ter como alvo uma plataforma específica, o .NET Core ou o .NET Framework. Ele não pode segmentar o .NET Standard, mesmo que o código que você está testando seja o .NET Standard. Isso ocorre porque o destino dos testes indica em qual plataforma executar os testes. O .NET Standard é como um PCL (Portable Class Library), pois pode ser executado em várias plataformas.

Em seguida, você precisa adicionar referências à Microsoft.NET.Test.Sdksua estrutura de teste de escolha e um adaptador de teste compatível. Para o NUnit, suas referências serão assim,

<itemgroup>
    <packagereference Include="Microsoft.NET.Test.Sdk" Version="15.0.0"></packagereference>
    <packagereference Include="NUnit" Version="3.7.1"></packagereference>
    <packagereference Include="NUnit3TestAdapter" Version="3.8.0"></packagereference>
</itemgroup>

Um comentário acima menciona a adição,

<ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>

Isso não é estritamente necessário, mas pode ajudar. Ele é adicionado automaticamente a todos os projetos de teste de unidade do Visual Studio para ajudá-lo a encontrar rapidamente projetos com testes.

Se seus testes não aparecerem no Visual Studio, a primeira coisa a tentar é fechar sua solução e reabri-los. Parece haver erros no Visual Studio que não detectam alterações nos projetos quando você os edita.

Para obter mais informações, consulte Testando o .NET Core com NUnit no Visual Studio 2017

Eu tive o mesmo problema e o fiz funcionar da seguinte maneira:

• Primeiro feche todas as instâncias abertas do Visual Studio e exclua esta pasta:% TEMP% \ VisualStudioTestExplorerExtensions. ( Executando testes com o Visual Studio )
• Vá para o gerenciador de pacotes Nuget e instale o Microsoft.NET.Test.Sdk (15.3.0-preview-20170425-07) primeiro e instale o xunit.runner.visualstudio (2.3.0-beta1-build1309). Veja a captura de tela do Nuget em anexo para ver todos os pacotes que tive que instalar para obter o VS 2017 mais recente para detectar meus testes.

Esquecendo de tornar pública a classe de teste impede os métodos de teste internos a serem descobertos

Eu tinha um projeto xUnit padrão e excluí o exemplo UnitTest1.cs, substituindo-o por uma classe de teste do controlador, por alguns testes, mas nenhum foi encontrado

Resumindo, depois de atualizar os pacotes xUnit, Test.Sdk, xUnit.runner e reconstruir o projeto, encontrei um erro de compilação:

As classes de teste xUnit1000 de erro devem ser públicas

Felizmente, a versão atualizada lançou essa exceção para me poupar alguns problemas

A modificação da classe de teste para ser pública corrigiu meu problema

No meu caso, eu direciono o projeto de teste para x64Arquitetura e a configuração de teste Arquitetura (teste-> Arquitetura padrão do processador) alterada foi definida como x86. Eles não combinaram.

Depois de voltar a configuração de teste, a arquitetura x64e a reconstrução de todos os testes foram descobertos novamente.

Também tive problemas com o VS 2017 para encontrar meu UnitTest. Não era o problema exato que John estava perguntando - mas este foi o primeiro resultado no google que eu procurei, por isso queria compartilhar meu problema.

Eu tinha uma solução legada voltando do VS2010 passando pelo VS2013, VS2015. Agora, no VS2017, parece que os namespaces do [TestMethod]Atributo foram alterados.

Antes de usar

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

Criei um novo Test.dll no projeto e aquele usado por padrão

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

Portanto, minha solução foi criar um novo projeto UnitTest no VS2017. Talvez alterar as referências de montagem para o projeto de teste antigo também funcionasse. Com a nova referência, o VS2017 descobriu esses testes de unidade.

Não leia artigos desatualizados no MSDN. Os materiais relevantes do .NET Core estão em docs.microsoft.com

https://docs.microsoft.com/en-us/dotnet/articles/core/testing/

De um modo geral, você precisa de um aplicativo de console do .NET Core para conter os casos de teste de unidade.

para mim problema foi eu coloquei testcases por engano em uma classe interna

[TestClass]
  internal class TestLib {
}

que estava causando a identificação de casos de teste.

Verifique se você está usando o Microsoft.NET.Test.Sdk correto:

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />

Não use um pré-lançamento. Ou você precisa alterar para o aplicativo de console (não para a biblioteca). Eu tenho o problema semelhante, mas com a versão mais recente (15.0.0), ele começa a funcionar novamente.

Além disso, você pode precisar adicionar:

  <ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
  </ItemGroup>

mas não acho que seja necessário.

Eu sei que o OP listou isso em sua lista de verificação, mas é fácil ignorar esse ponto ao fazer uma instalação limpa do Visual Studio 2017 e configurar um novo projeto. Além do modelo de projeto NUnit e do NUnit Framework, é necessário instalar o adaptador NUnit separadamente, por exemplo, usando o comando NuGet Install-Package NUnit3TestAdapter -Version 3.9.0. Depois disso, a Comunidade do Visual Studio 2017 começou a descobrir testes de unidade sem problemas.

No meu caso, o Test Explorer não pôde encontrar meus testes depois que eu mudei o projeto para uma nova solução.

A resposta foi simplesmente que eu tinha uma referência ao antigo MS Test Adapter no meu projeto.

Eu tinha uma duplicata da linha abaixo para a versão 1.1.11 do MS Test Adapter no meu arquivo cs.proj:

<Import Project="..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props')" />

Para consertar o problema,

1. Clique com o botão direito do mouse no projeto e selecione 'Descarregar projeto'.
2. Clique com o botão direito do mouse no projeto e selecione 'Editar'
3. Remova a linha que importa a versão antiga do adaptador.
4. Clique com o botão direito do mouse no projeto e selecione 'Recarregar projeto'.
5. Reconstruir solução / projeto

Só tive esse problema com o visual studio não conseguir encontrar meus testes, não consegui ver o botão para executá-los além do método e eles não foram detectados ao executar todos os testes no projeto.

Acontece que minha classe de teste não era pública! Tornar público permitiu ao VS descobrir os testes.

Para mim, foi mais fácil criar um novo projeto de teste que funcione perfeitamente com o Visual Studio 2017 ... e apenas copiar os arquivos de teste, adicionar referências e pacotes NuGet, conforme necessário.

No meu caso, foi um projeto que eu atualizei o projeto de teste de uma versão anterior do .Net. no app.config eu tinha ligações de montagem para versões anteriores das montagens dependentes.

Depois de corrigir as assembllybindings no app.config, meus testes foram descobertos.

Descoberta

As principais respostas acima não funcionaram para mim (reiniciando, atualizando para a versão 1.1.18 ... Eu já estava atualizado, excluindo os arquivos temporários, limpando o cache do NuGet etc.).

O que descobri é que eu tinha referências diferentes ao MSTest.TestAdapter e MSTest.Framework em diferentes projetos de teste (minha solução tem dois). Um deles foi apontado para 1.1.18 como ...

packages.config

<package id="MSTest.TestAdapter" version="1.1.18" targetFramework="net461" />
<package id="MSTest.TestFramework" version="1.1.18" targetFramework="net461" />

... mas outro tem as referências ao 1.1.11. Algumas das respostas acima levam a essa descoberta quando duas versões das bibliotecas apareceram no meu diretório temporário (% TEMP% \ VisualStudioTestExplorerExtensions \) após reiniciar o Visual Studio.

Solução

Simplesmente atualizar meu packages.config para a versão 1.1.18 é o que restaurou minha funcionalidade de testes de unidade no VS. Parece que existem alguns erros que não permitem referências lado a lado das bibliotecas do MSTest. Espero que isso ajude você.

Mais informações:

• Visual Studio 2017 Ent: 15.5.6 (eu atualizei a partir do 15.0.1 com esperanças de corrigir esse problema, mas o tive nos dois)

A solução foi remover meu app.configarquivo do meu projeto de teste de unidade. Os testes reaparecerão!

Este arquivo referenciou algumas DLLs nos diretórios de ligação que não estavam realmente presentes nas referências do projeto. Volte a adicionar as ligações de montagem estritamente necessárias para o seu projeto.

No meu caso, foi o projeto UWP presente na solução que causou o problema.

Quando eu descarreguei o projeto UWP, os testes foram descobertos. Quando o carreguei novamente, o teste desapareceu novamente.

Tente descarregar todos os projetos e mantenha apenas o projeto de teste. Dez soluções de reconstrução e shound de teste aparecem no Test Runner. Carregue os projetos um por um e reconstrua a solução a cada vez para descobrir qual projeto está causando o problema

repositório de amostras

Relatório de bug do VS

O problema

O problema é que o Visual Studio está ficando 'confuso' com as versões principais do dotnet na máquina. Quando fui ao painel de controle -> desinstalar programas, eu tinha 8 SDKs e Runtimes diferentes do core dotnet instalados. De alguma forma, isso causou um erro silencioso no VS ao tentar encontrar testes.

Validar o problema

Você pode validar o problema acessando a linha de comando e recebendo a versão do dotnet $ dotnet --version. Se você vir alguma coisa, exceto a versão mais recente que você instalou, sua máquina possui alguma incompatibilidade e não está usando a versão correta. Exemplo ... Se você possui o dotnet core 1.0.1instalado, mas quando obtém a versão no prompt de comando e diz que 1.0.0é um problema.

A solução

Exclua todas as coisas antigas. Comecei apenas com o que eu precisava remover (as versões mais antigas do dotnet rc), mas ele ainda deu a versão errada ao testar o problema. Eventualmente, eu concedi fazer uma limpeza completa. EU...

• Desinstalou todos os aplicativos do visual studio (na minha máquina VS2015 e VS2017)
• Desinstalou todas as versões do dotnet core (mesmo as mais recentes)

Depois que minha máquina estava completamente vazia de todos os VS e donets, instalei apenas o VS2017 (ele vem com o dotnet mais recente). Criei um projeto de teste xUnit e o explorador de testes encontrou o teste imediatamente RESOLVIDO

Isso pode parecer um exagero, mas passei duas semanas tentando consertar isso de outras maneiras. Se você tiver apenas o problema, mesmo que demore horas para desinstalar / reinstalar itens, provavelmente você economizará tempo.

Referências

• Veja @epestic blog post onde ele fornece mais detalhes sobre como corrigir o problema.

Eu tentei de tudo, mas nada ajudou. No meu caso, eu tinha uma solução com vários projetos de teste e alguns deles estavam usando a antiga estrutura de teste do ms, então o Visual Studio encontrou apenas esses.

Instalei os pacotes da estrutura de teste para todos os projetos de teste, conforme mostrado na resposta aceita . Em seguida, removemos as referências às ferramentas de qualidade antigas, reiniciei o Visual Studio e agora posso ver todos os testes.

Para C ++:

Como não há uma pergunta especial para os testes C ++, mas o tópico é praticamente o mesmo, eis o que me ajudou quando tive problemas com a descoberta de testes.

Se você instalou apenas o desenvolvimento da área de trabalho com C ++ , a solução é instalar também o desenvolvimento da Plataforma Universal do Windows com as ferramentas opcionais da Plataforma Universal do Windows C ++ . Você pode selecioná-los no instalador da web do visual studio.

Depois, reconstrua o seu projeto de teste e a descoberta do teste deverá funcionar.

Btw, eu criei o projeto de teste de unidade no VS2017. Pode ser importante, porque alguns usuários mencionaram, que eles tiveram problemas de descoberta em projetos que foram migrados do VS2015 para o VS2017.

Remover .dll antigo deve ajudar. Limpando arquivos temporários localizados no diretório% TEMP% em C: \ Users (yourusername) \ AppData \ Local \ Temp

Eu tive o mesmo problema. Minha solução estava boa, mas de repente, quando abri a solução, descobri que os testes haviam acabado.

Finalmente, fiz o downgrade Microsoft.VisualStudio.TestPlatform.TestFrameworke os Microsoft.VisualStudio.TestPlatform.TestFramework.Extensionspacotes para uma versão muito antiga (usando o NuGet manager) e os métodos de teste apareceram. Então eu atualizei para a versão mais recente e ainda havia lá.

Então, basta fazer o downgrade e atualizar os pacotes.

No meu caso, nenhuma das opções acima me ajuda. Mas, faço o downgrade do NUNit3TestAdapter para a versão 3.8.0 e depois atualizo para a versão mais recente (3.10.0)

Às vezes, alterar o espaço para nome dos testes funciona. Eu tinha a estrutura de pastas da seguinte maneira:

A |___B | |___D |___C___E

O espaço para nome era plano como Testes. <Nome> e eles não apareciam na janela de teste. Quando mudei o namespace para a estrutura do diretório, todos os testes apareceram. Agora eu poderia voltar para qualquer outra estrutura de namespace que eu quiser.

Não esqueça de construir seu projeto!

No caso do .NET Framework, no projeto de teste, anteriormente havia referências às seguintes DLLs:

Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions

Excluí-os e adicionei referência a:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

E então todos os testes apareceram e começaram a funcionar da mesma maneira que antes.

Eu tentei quase todas as outras sugestões acima antes, mas simplesmente refazer a referência às DLLs de teste funcionou bem. Publiquei esta resposta para aqueles que estão no meu caso.

Eu estava enfrentando o mesmo problema, no meu caso, para resolver

1. Abri o console do Windows (tecla Windows + cmd).
2. Navegue para a pasta em que o projeto foi criado.
3. Executado o comando "dotnet test", é basicamente o mesmo teste que o visual studio executa, mas quando você o executa no console, permite ver o rastreamento completo.
4. Recebi esta mensagem de erro "Atributo TestClass definido na classe não pública MSTest.TestController.BaseTest"
5. Então fui ao caso de teste e o marquei como público, construí novamente e meus testes estão sendo exibidos corretamente

No começo, eu tentei usar o MSTest. Depois disso, mudo para o teste da unidade. Então eu queria fazer o backup do MSTest. Eu removi todos os códigos e referências do nUnit, mas o Test Explorer não mostrou os métodos MSTest. Solução: removi todas as referências de nuget da mstest e reinstalei. Feito.

Para mim, alterar o TargetFramework no .csprojarquivo do projeto de teste de

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

para

  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

trabalhou.

No meu caso, o problema era que o tipo de projeto estava definido como biblioteca estática (lib) e deveria ser uma biblioteca dinâmica (dll)