Nunit: Suporta `dotnet test` em .NET CLI e .NET Core

Estávamos esperando que o .NET Core se acomodasse um pouco antes de avançarmos com o # 927, é por isso que ele não foi atualizado com um novo título e informações. Eu estava planejando esperar por quaisquer anúncios que possam vir em // build antes de prosseguirmos, mas agradeceríamos qualquer ajuda que pudermos obter. Meu plano é começar a fornecer suporte mais completo para mais plataformas com o lançamento 3.4 neste verão, incluindo .NET Core, UWP e Xamarin.

Você forneceu um resumo bem escrito aqui, então vou encerrar o número 927 e usar este problema para rastreamento daqui para frente. Se você quiser ajudar com esse problema, podemos coordenar, mas gostaria de receber sua ajuda.

A primeira etapa neste processo foi criar um driver / agente PCL que pode carregar e executar testes sem estar fortemente vinculado a uma versão específica do NUnit Framework como o NUnitLite e o atual Xamarin runner. Ainda está em sua infância, mas o trabalho em andamento está no projeto nunit.portable.agent .

Qualquer ajuda ou conselho que @piotrpMSFT ou @livarcocc possam dar também seria apreciada: smile:

@rprouse Eu tenho um bug na CLI para escrever uma documentação melhor sobre as interações e requisitos entre o teste dotnet e o runner. Vou fazer hoje ou amanhã e vou colocar um link para isso aqui.

Este é o rastreamento de bug: https://github.com/dotnet/cli/issues/1803.

Como esta indo Eu adoraria usar isso, e o ecossistema dotnet cli parece estar se estabilizando.

Estou fazendo alguns progressos, mas não quero fazer muito até que o RC2 seja removido. Estou ficando cansado de tentar acompanhar as mudanças: sorria:

O .NET Core RC2 foi lançado e novas informações estão disponíveis. Links para referência.

• comando dotnet-test
• protocolo de comunicação dotnet-test

Posso ajudar alguém aqui? Este é um bloqueador para completar algumas de nossas portas como StackExchange.Redis.

@NickCraver Eu definitivamente

Os primeiros passos são decidir como vamos abordar isso. Atualmente, temos a compilação portátil voltada para o .NET Core, mas é limitante. Estou pensando em criar uma compilação básica da estrutura, mas não tenho certeza se preciso ou devo.

Em seguida, preciso ver o que é necessário para criar uma extensão de teste para o comando dotnet .

Por último, gostaria que o mecanismo nunit fosse capaz de iniciar e se comunicar com um agente nunit principal para que o console nunit3 pudesse executar testes de unidade do .NET Core. Tenho trabalhado nisso, mas ainda tenho muito trabalho a fazer lá.

Como você gostaria de ajudar?

@rprouse Eu acho que você terá que ter um build principal para possivelmente ser usado em várias plataformas, esse é um recurso crítico.

Não tenho certeza de quanto tempo podemos dedicar a isso em vez de investir em outro lugar, embora, para ser honesto, dada a quantidade de trabalho que resta. Por enquanto, preciso disponibilizar as bibliotecas para muitas pessoas que estão esperando para criar suas bibliotecas e aplicativos. Eu odeio dizer isso, mas dado o atraso aqui vs. o que está disponível hoje, acho que teremos que terminar de portar tudo para o xUnit, caso contrário, muitas centenas a milhares de desenvolvedores estão esperando por uma cadeia bloqueada de lançamentos aqui.

Vou tentar revisitar isso depois que estivermos estáveis ​​e o tempo permitir, mas (e me corrija se eu estiver errado) no momento, estamos falando de semanas de trabalho restantes (passando pelo seu posto) antes de mim ' d ser capaz de usar isso para executar o que espero seja portas de biblioteca concluídas e prontas para envio. Do ponto de vista do dever do autor, primeiro preciso desbloquear as pessoas para mim e, em seguida, ajudar no processo de criação.

@NickCraver, em vez de gastar o esforço portando para o xUnit, pode ser mais fácil criar um executor NUnitLite de linha de comando para executar seus testes do .NET Core. Não é uma solução perfeita, mas possivelmente dá menos trabalho. Está um pouco desatualizado, mas escrevi sobre como fazer isso em Testing .NET Core using NUnit 3 .

Estou fazendo isso para alguns projetos pessoais e é funcional.

Eu ficaria feliz em ajudar a obter uma compilação dotnet-test-nunit adequada por aí. Tenho certeza de que muitas pessoas se beneficiariam. Grande parte do contrato definido no protocolo já está implementado em uma biblioteca auxiliar. Se tivermos um runner de nunit xplat funcionando, isso deve dar pouco trabalho.

Ajudaria a dividir isso em duas fases - uma espécie de lançamento "rápido e sujo, pode ter hacks grotescos, mas pelo menos vamos fazer algo por aí" e, em seguida, uma integração mais completa mais tarde?

(Estar prestes a construir os testes com um TFM de netstandard1.3 seria um longo caminho para me desbloquear para a Hora de Noda, por exemplo.)

@jskeet e @NickCraver você pode usar o NUnit hoje por meio do "hack" do NUnitlite como

@roji : Isso funcionou com dnxcore50 (eu tenho usado com o Noda Time por um tempo) - mas usando netstandard1.3 , as dependências de NUnit e NUnitLite são inválidas.

@jskeet meu projeto de teste visa netcoreapp1.0 e depende do Nunit + NUnitLite 3.2.1. Eu tenho "imports" : [ "dotnet54" ] e funciona perfeitamente ...

@roji : Obrigado por isso ... dedos cruzados ...

@roji : Ainda estou tendo problemas para executar os testes - você poderia fazer um link para onde está fazendo isso em seu projeto de teste, como um exemplo a seguir?

@jskeet claro, aqui está: https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.Tests

@jskeet, as importações também devem funcionar para você. RC2 muda algumas coisas, então vou reescrever minha postagem do blog sobre como testar com o NUnit 3 com RC2 em mente e postar o código no GitHub. Adicionarei um link aqui quando estiver pronto, espero que esta manhã (EST).

@piotrpMSFT você pode me poupar algum tempo e indicar a biblioteca auxiliar para a criação de dotnet-test-nunit ? Eu posso pesquisar, mas estou perseguindo várias coisas no momento, então a ajuda seria apreciada. Tenho certeza de que você também está ocupado, então, se não o tiver em mãos, não perca tempo com ele, eu o encontrarei.

Eu postei uma postagem de blog atualizada Testando o .NET Core RC2 usando o NUnit 3 para qualquer pessoa interessada.

@jskeet você precisa da declaração de importações em seu project.json. Ele é adicionado por padrão nos novos modelos do .NET Core, mas precisa ser adicionado durante a atualização.

Para project.json em um executor de console;

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }

Ou em uma assembléia;

  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"
    }

Ao atualizar para o RC2, ter coisas antigas do DNX no meu caminho também me incomodou. Algo para verificar.

@rprouse : Obrigado; Agora posso construir e os testes são executados no Windows. No Linux, estou vendo uma "Referência de objeto não definida para uma instância de um objeto." mensagem em dotnet run , que preciso investigar mais a fundo. Tentaremos sua amostra mínima para ver se tem o mesmo problema ...

@jskeet , estamos usando essa abordagem no Windows e no Linux sem problemas. Veja aqui e aqui exemplos.

@oschwald : Sim, parece que o problema com "Referência de objeto não definida ..." é um problema muito separado com dependências. É uma pena que a mensagem de erro seja tão inútil (sem nem mesmo um rastreamento de pilha) - estou investigando.

@jskeet Existem algumas causas, é sua? https://github.com/dotnet/cli/issues/3075

@NickCraver : Não - fiz uma restauração dotnet com sucesso.

No meu caso, tenho um arquivo project.json que funciona sem dependência de outro projeto, mas falha com ele. Preciso dedicar mais tempo para fazer uma reprodução completa.

@jskeet Gotcha - relevante: https://github.com/dotnet/cli/issues/2469 e o canal Slack é ótimo para project.json depuração ao vivo, apareça com exemplos e você geralmente pode começar bem rápido. Para o Slack, os canais #general e # dotnet-core são bastante ativos, muitas pessoas passando por isso e ajudando outra pessoa.

Hmm ... e agora está funcionando. É possível que fosse o mesmo problema que @NickCraver relatou e que eu estava apenas dotnet restore -ing no projeto errado para consertá-lo. De qualquer forma, agora estou executando os testes do Noda Time no Linux, então yay :) Obrigado a todos.

@piotrpMSFT re o meu pedido de ponteiros, encontrei tudo o que preciso e comecei a trabalhar.

Eu adicionei um PR inicial para o dotnet-test-nunit runner em nunit / dotnet-test-nunit # 1

Ele explora e executa testes, mas ainda precisa de algum trabalho, limpeza e teste. Vou tornar o feed do NuGet para os artefatos de construção mais acessível se alguém quiser brincar com ele.

Se alguém tiver idéias sobre como posso depurar o pacote NuGet quando ele for carregado pelo Visual Studio, eu poderia usar um pouco de ajuda. Até agora, ele não está sendo executado no Visual Studio, mas isso pode ser um problema de configuração.

@rprouse : Eu ficaria feliz em ver como o Noda Time lida com isso, se isso for útil. Avise-me se houver algo em particular que você gostaria que eu verificasse. Obrigado por todo o seu trabalho!

Ainda não está pronto para o horário nobre, mas tenho testes do NUnit .NET Core em execução no console e no Visual Studio. Ainda há vários problemas a serem resolvidos antes de eu lançar um alfa, mas agora estamos muito mais próximos, pois o trabalho árduo é feito e se resume aos detalhes.

Vou postar detalhes sobre como testar a construção do CI depois de corrigir alguns problemas. Eu apreciaria se as pessoas pudessem chutar os pneus e me ajudar a encontrar problemas.

Aqui está uma captura de tela.

@rprouse : Algum progresso na construção do CI? Definitivamente ansioso para chutar os pneus; Noda Time usa um número _razoável_ de recursos NUnit, então deve ser um bom começo, de qualquer maneira. Estou realmente ansioso para poder executar testes no VS novamente. (Espero que NCrunch e CodeRush para Roslyn comecem a apoiá-lo assim que for lançado também ...)

@jskeet e outros que estão interessados ​​em chutar os pneus e me ajudar a testar antes de lançar um alfa, atualizei meu repositório de demonstração em um branch dotnet-test-nunit para usar o novo dotnet-test-nunit runner.

Relate os problemas no repositório nunit / dotnet-test-nunit .

As instruções de alto nível são;

Atualização: dotnet-test-nunit agora está disponível como um alfa no NuGet, selecione Include prereleases . Você não precisa mais atualizar seu arquivo nuget.config .

dotnet-test-nunit ainda está em desenvolvimento, então você precisará adicionar um arquivo NuGet.Config à sua solução para baixar pacotes NuGet dos feeds NUnit CI NuGet.

Seu project.json em seu projeto de teste deve ser parecido com o seguinte;

project.json

{
    "version": "1.0.0-*",

    "dependencies": {
        "NUnitWithDotNetCoreRC2": "1.0.0-*",
        "NETStandard.Library": "1.5.0-rc2-24027",
        "NUnit": "3.2.1",
        "dotnet-test-nunit": "3.4.0-alpha-1"
    },
    "testRunner": "nunit",

    "frameworks": {
        "netstandard1.5": {
            "imports": [
                "dnxcore50",
                "netcoreapp1.0",
                "portable-net45+win8"
            ]
        }
    },

    "runtimes": {
        "win10-x86": { },
        "win10-x64": { }
    }
}

As linhas de interesse aqui são a dependência de dotnet-test-nunit . Sinta-se à vontade para usar a versão de pré-lançamento mais recente que termina em -CI , que é a última versão do branch master. Observe que a dependência NUnitWithDotNetCoreRC2 é o projeto em teste.

Eu adicionei "testRunner": "nunit" para especificar o NUnit 3 como o adaptador de teste. Eu também tive que adicionar às importações para o adaptador de teste e NUnit para resolver. Por último, tive que adicionar runtimes . Se alguém puder explicar por que preciso fazer isso, por favor, me avise.

Agora você pode executar seus testes usando o Visual Studio Test Explorer ou executando dotnet test na linha de comando.

# Restore the NuGet packages
dotnet restore

# Run the unit tests in the current directory
dotnet test

# Run the unit tests in a different directory
dotnet test .\test\NUnitWithDotNetCoreRC2.Test\

Aviso

Como eu disse, isso ainda está em desenvolvimento. dotnet-test-nunit versão 3.3.0.39-CI listada acima tem um bug onde irá lançar um ArgumentException ao tentar salvar o arquivo TestResult.xml .

Observe também que a linha de comando dotnet engole linhas em branco e não funciona com cores. A saída do executor de teste NUnit é colorida, mas você não a verá.

A parte "engolir a linha em branco" é um bug conhecido: https://github.com/dotnet/cli/issues/2234

Obrigado pelo link @jskeet , parece que a cor também é um bug conhecido, dotnet / cli # 1977

O ArgumentException foi corrigido em 3.3.0.49-CI . Vou atualizar minhas instruções acima com a correção. Um outro problema pendente é que no momento não estou fornecendo o número da linha para testes ao executor, portanto, clicar em testes no Explorador de Testes do Visual Studio não levará você ao código.

Estou certo em dizer que ainda não há suporte para argumentos de linha de comando, como --where etc? (Eu entendo perfeitamente que é cedo - apenas tentando verificar se isso é algo que eu deveria ser capaz de fazer.)

Tentei um project.json ligeiramente diferente para você. Eu incluí abaixo na íntegra, mas as diferenças importantes são:

• Eu quero testar o tempo de execução da área de trabalho também, então tenho dois destinos de framework
• Estou usando netcoreapp1.0 vez de netstandard1.5
• Incluí a dependência Microsoft.NETCore.App , com "type"="platform"
• Olha mãe, nenhuma seção de tempo de execução. (Possivelmente devido a algumas das mudanças acima ...)

{
  "buildOptions": {
    "keyFile": "../../NodaTime Release.snk",
    "embed": {
      "include":  [   
        "TestData/*"
      ]
    }
  },

  "configurations": {
    "Debug": {
      "buildOptions": {
        "define": [ "DEBUG", "TRACE" ]
      }
    },
    "Release": {
      "buildOptions": {
        "define": [ "RELEASE", "TRACE" ],
        "optimize": true
      }
    }
  },

  "dependencies": {
    "NodaTime": { "target": "project" },
    "NodaTime.Testing": { "target": "project" },
    "NUnit": "3.2.1",
    "dotnet-test-nunit": "3.3.0.49-CI",
    "Microsoft.CSharp": "4.0.1-rc2-24027",
    "System.Dynamic.Runtime": "4.0.11-rc2-24027",
    "System.Reflection.Extensions": "4.0.1-rc2-24027",
    "System.Xml.XDocument": "4.0.11-rc2-24027"
  },

  "testRunner": "nunit",

  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Threading.Tasks": "",
        "System.Xml.Linq": ""
      }
    },
    "netcoreapp1.0": {
      "imports" : [ "dnxcore50", "netcoreapp1.0", "portable-net45+win8" ],
      "buildOptions": {
        "define": [ "PCL" ]
      },
      "dependencies": {
        "Microsoft.NETCore.App": { 
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        },
        "System.Console": "4.0.0-rc2-24027",
      }
    }
  }
}

Resultado:

Test Count: 15141, Passed: 15141, Failed: 0, Inconclusive: 0, Skipped: 0

Woot. (Usando net451, obtenho uma contagem de teste de 15646, que é o que eu esperava.)

A seguir: tentar a mesma coisa em uma máquina Linux (onde seu project.json provavelmente não funcionaria sem modificação, pois não menciona o Linux, mas o meu deveria, em teoria; tendo dito isso, é uma máquina Ubuntu 16.04, então é dotnet CLI é um pouco encorpado).

Hmm. Os testes no Linux não terminaram após 14 minutos comendo 100% da CPU. Precisará examinar mais de perto o que está acontecendo lá.

@jskeet

Estou certo em dizer que ainda não há suporte para argumentos de linha de comando, como --where etc?

Mal testado, mas conectei --where e a maioria dos parâmetros de linha de comando comuns. Ainda tenho um problema, nunit / dotnet-test-nunit # 4 para verificar se todos eles estão conectados corretamente e funcionam e adicionar qualquer um que possa estar faltando. Até agora, não testei muitos, mas usei alguns adicionando-os ao final do comando dotnet . Ainda preciso descobrir exatamente como funciona. Por exemplo, a opção de linha de comando --debug estava funcionando bem com a solução dotnet-test-nunit , mas gerou dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" quando a executo a partir da minha solução de teste. Também não tenho ideia de como encadear a linha de comando de ajuda com a nossa para mostrar o que é compatível.

Enquanto isso, você pode dar uma olhada em https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs para ver quais opções de linha de comando eu acho suportado: sorriso:

Ah, sim - parece que dotnet test não tem a mesma facilidade que dotnet run para separar argumentos para a estrutura de teste dos argumentos para dotnet test si. Eu estava tentando

dotnet test -- --help

e

dotnet test -- --where=cat!=Slow

Apenas usando

dotnet test --where=cat!=Slow

funciona bem. Arquivaremos uma solicitação de recurso para isso - é bom ser totalmente inequívoco.

Clicar nos testes e navegar até o código agora está corrigido em 3.3.0.60-CI .

Ainda há dois problemas de alta prioridade, então estou planejando fazer uma versão alfa, quando fecharei esse problema e rastrearei tudo no novo repositório. As duas questões são;

• [x] nunit / dotnet-test-nunit # 22 Adicionar mensagens e rastreamentos de pilha a testes com falha
• [x] nunit / dotnet-test-nunit # 12 TestContext.WriteLine não aparece no resumo do teste TestExplorer

Apenas como um FYI, eu executei os testes Noda Time novamente hoje na minha caixa do Ubuntu, e eles foram concluídos após cerca de 15 minutos. Parece que eles estão rodando cerca de 5-6x mais devagar no meu Linux i5 do que no Win10 i7. Não tenho certeza de quanto isso tem a ver com CPU e quanto tem a ver com JIT - e está definitivamente fora do escopo do NUnit :)

@jskeet obrigado pela atualização, essa é uma boa notícia. Você precisou de ligações mono para os testes do Linux, conforme indicado em nunit / dotnet-test-nunit # 9?

Para qualquer um que esteja testando, o pacote NuGet mais recente e bom é 3.3.0.69-CI , teste com ele. Agora não há nenhum problema pendente que eu acho que seja sério o suficiente para bloquear um lançamento. Se nenhum for relatado esta semana, provavelmente irei criar uma versão alfa no final desta semana ou no início da próxima semana. Depois de fazer isso, encerrarei esta edição e discussões / questões futuras podem prosseguir no repo dotnet-test-nunit .

Teste agora ou fique quieto para sempre: sorria:

@rprouse : Eu não tentei executá-lo no Mono - apenas .NET Core no Linux. Isso funcionou bem com o project.json exato acima.

Vai dar um giro no 69-CI ...

Uma diferença que notei entre este e o executor do aplicativo de console é que a versão "dotnet test" parece incluir o tempo gasto para encontrar testes na duração geral, enquanto o comando "dotnet run" que eu costumava usar com o NUnitLite não . Em Noda Time, isso significa que se eu executar com --where=cat==Foo (não existem tais testes nessa categoria), "teste dotnet" relata uma duração de 14s, enquanto "dotnet run" relata uma duração de 0,01s - apesar ambos levando aproximadamente o mesmo tempo real decorrido.

Isso é deliberado? Certamente não me importo com o comportamento, mas pode valer a pena observá-lo em algum lugar para evitar que as pessoas pensem que é realmente mais lento.

@jskeet, essa é uma boa observação, realmente é o caso. Como não temos o mecanismo NUnit completo para executar os testes, o código é mais simplista, mas talvez eu consiga iniciar o relógio no primeiro evento de teste iniciado em vez de encerrar a execução do teste. Vou inserir um problema.

Lancei uma versão alfa de dotnet-test-nunit no GitHub em https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 , então você não precisa mais alterar seu NuGet.config file e use versões CI.

Agora que tenho um alfa lançado, vou encerrar este problema. Ajude-me a testar o alfa e relatar quaisquer problemas em https://github.com/nunit/dotnet-test-nunit/issues. O lançamento final está planejado para sair no final do mês com o lançamento do NUnit 3.4. Vou lançar alfas e betas atualizados dependendo dos problemas encontrados.

Eu atualizei a documentação no leia-me para dotnet-test-nunit . Vou manter isso atualizado.

https://github.com/nunit/dotnet-test-nunit

Como observei antes, você não precisa especificar os tempos de execução se usar "type": "platform" para a dependência "Microsoft.NETCore.App" . Dados os documentos do xUnit, acho que essa é a abordagem preferida.

No momento, tenho uma solicitação de pull em execução no Travis - se for verde, o Noda Time dependerá disso, de modo que deve dar a ela _alguma_ utilização. Muito bem, senhor ...

Uma desvantagem que notei agora - isso significa que não posso mais testar facilmente com Mono no Linux. Acredito que não seja um problema NUnit, é basicamente uma manifestação de https://github.com/dotnet/cli/issues/3073, mas para NUnit. Ainda estou esperançoso de que isso possa ser consertado eventualmente; por enquanto, desabilitarei meus testes de mono no Travis, com um pouco de relutância. ( dotnet test definitivamente é o futuro.)