Nunit: Prise en charge du « test dotnet » dans .NET CLI et .NET Core

Nous attendions que .NET Core s'installe un peu avant de passer au #927, c'est pourquoi il n'a pas été mis à jour avec un nouveau titre et de nouvelles informations. J'avais prévu d'attendre les annonces qui pourraient sortir à //build avant d'aller de l'avant, mais nous apprécierions toute aide que nous pouvons obtenir. Mon plan est de commencer à fournir un support plus complet pour plus de plates-formes avec la version 3.4 cet été, y compris .NET Core, UWP et Xamarin.

Vous avez fourni un résumé bien écrit ici, je vais donc clore le numéro 927 et utiliser ce numéro pour le suivi à l'avenir. Si vous voulez aider avec ce problème, alors nous pouvons coordonner, mais je serais ravi de votre aide.

La première étape de ce processus consistait à créer un pilote/agent PCL capable de charger et d'exécuter des tests sans être étroitement lié à une version spécifique de NUnit Framework comme NUnitLite et l'exécuteur Xamarin actuel. Il en est encore à ses balbutiements, mais le travail en cours se trouve dans le projet nunit.portable.agent .

Toute aide ou conseil que @piotrpMSFT ou @livarcocc peut donner serait également apprécié :sourire:

@rprouse J'ai un bug sur la CLI pour écrire une meilleure documentation concernant les interactions et les exigences entre dotnet test et le runner. Je vais le faire aujourd'hui ou demain et je mettrai un lien ici.

Voici le bogue qui le suit : https://github.com/dotnet/cli/issues/1803.

Comment ça se passe ? J'adorerais l'utiliser, et l'écosystème dotnet cli semble se stabiliser.

Je fais des progrès, mais je ne veux pas en faire trop avant que RC2 tombe. J'en ai marre d'essayer de suivre les changements :sourire:

.NET Core RC2 a été publié et de nouvelles informations sont disponibles. Liens pour référence.

• commande dotnet-test
• protocole de communication dotnet-test

Puis-je aider quelqu'un ici ? Ceci est un bloqueur pour compléter certains de nos ports comme StackExchange.Redis.

@NickCraver Je pourrais certainement avoir

Les premières étapes sont de décider comment nous allons aborder cela. Nous avons actuellement la version portable qui cible .NET Core, mais elle est limitée. J'envisage de créer une version de base du framework, mais je ne sais pas si j'en ai besoin ou si je devrais.

Ensuite, je dois regarder ce qu'il faut pour créer une extension de test pour la commande dotnet .

Enfin, j'aimerais que le moteur nunit puisse se lancer et communiquer avec un agent nunit de base afin que nunit3-console puisse exécuter des tests unitaires .NET Core. J'ai travaillé là-dessus, mais j'ai encore beaucoup de travail à faire.

Comment aimeriez-vous vous aider?

@rprouse Je pense que vous devrez avoir une version de base pour éventuellement être utilisée sur plusieurs plates-formes, c'est une fonctionnalité critique.

Je ne sais pas combien de temps nous pouvons consacrer à cela par rapport à investir ailleurs, mais pour être honnête, étant donné la quantité de travail qui reste. Pour l'instant, je dois ouvrir la porte des bibliothèques à de nombreuses personnes en aval qui attendent de créer leurs bibliothèques et leurs applications. Je déteste dire cela, mais étant donné le décalage ici par rapport à ce qui est disponible aujourd'hui, je pense que nous devrons finir de tout porter sur xUnit, sinon des centaines à des milliers de développeurs attendent une chaîne bloquée de versions ici.

J'essaierai de revoir cela une fois que nous serons stables et que le temps le permettra, mais (et corrigez-moi si je me trompe) pour le moment, nous parlons des semaines de travail restantes (en passant par votre poste) avant que je ' d pouvoir l'utiliser pour exécuter ce que j'espère être des ports de bibliothèque finis prêts à être expédiés. Du point de vue du devoir d'auteur, je dois d'abord débloquer les gens sur moi, puis aider en amont comme je peux.

@NickCraver plutôt que de consacrer l'effort au portage vers xUnit, il peut être plus facile de créer un programme d'exécution NUnitLite en ligne de commande pour exécuter vos tests .NET Core. Ce n'est pas une solution parfaite, mais peut-être la moindre quantité de travail. C'est un peu obsolète, mais j'ai expliqué comment le faire sur Testing .NET Core à l'aide de NUnit 3 .

Je fais comme ça pour quelques projets personnels et c'est fonctionnel.

Je serais heureux de vous aider à obtenir une version appropriée de dotnet-test-nunit. Je suis sûr que beaucoup de gens en bénéficieraient. Une grande partie du contrat défini dans le protocole est déjà implémentée dans une bibliothèque d'assistance. Si nous avons un coureur nunit xplat fonctionnel, cela devrait être peu de travail.

Cela aiderait-il de diviser cela en deux phases - une sorte de version "rapide et sale, peut-être des hacks minables, mais au moins sortons quelque chose là-bas", puis une intégration plus complète plus tard?

(Le simple fait d'être sur le point de construire les tests avec un TFM de netstandard1.3 contribuerait grandement à me débloquer pour Noda Time, par exemple.)

@jskeet et @NickCraver, vous pouvez utiliser NUnit aujourd'hui via le "hack" NUnitlite comme

@roji : Cela a fonctionné avec dnxcore50 (je l'utilise avec Noda Time depuis un certain temps) - mais en utilisant netstandard1.3 , les dépendances sur NUnit et NUnitLite ne sont pas valides.

@jskeet mon projet de test cible netcoreapp1.0 et dépend de Nunit+NUnitLite 3.2.1. J'ai "imports" : [ "dotnet54" ] et ça marche comme un charme...

@roji : Merci pour ça...

@roji : J'ai toujours du mal à exécuter les tests - pourriez-vous établir un lien vers l'endroit où vous faites cela dans votre projet de test, comme exemple à suivre ?

@jskeet bien sûr, c'est https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.Tests

@jskeet, les importations devraient également fonctionner pour vous. RC2 change quelques choses, je vais donc réécrire mon article de blog sur la façon de tester avec NUnit 3 avec RC2 à l'esprit et publier le code sur GitHub. J'ajouterai un lien ici quand ce sera fait, j'espère ce matin (HNE).

@piotrpMSFT pouvez-vous me faire gagner du temps et m'indiquer la bibliothèque d'aide pour la création de dotnet-test-nunit ? Je peux chercher, mais je suis en train de chercher plusieurs choses en ce moment, donc de l'aide serait appréciée. Je suis sûr que vous êtes aussi occupé, alors si vous ne l'avez pas sous la main, ne perdez pas de temps dessus, je le trouverai.

J'ai publié un article de blog mis à jour Tester .NET Core RC2 à l'aide de NUnit 3 pour toute personne intéressée.

@jskeet, vous avez besoin de la déclaration d'importation dans votre project.json. Il est ajouté par défaut dans les nouveaux modèles .NET Core, mais doit être ajouté lors de la mise à niveau.

Pour project.json dans un exécuteur de console ;

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

Ou dans une assemblée ;

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

Lors de la mise à niveau vers RC2, avoir de vieux trucs DNX sur mon chemin m'a également mordu. Quelque chose à vérifier.

@rprouse : Merci ; Je suis maintenant capable de construire et les tests s'exécutent sous Windows. Sous Linux, je vois une "référence d'objet non définie sur une instance d'objet". message sur dotnet run , que je dois approfondir. J'essaierai votre échantillon minimal pour voir si cela a le même problème...

@jskeet , nous utilisons cette approche sur Windows et Linux sans problème. Voir ici et ici pour des exemples.

@oschwald :

@jskeet Il y a plusieurs causes, est-ce la vôtre ? https://github.com/dotnet/cli/issues/3075

@NickCraver : Non - j'ai effectué une restauration dotnet avec succès.

Dans mon cas, j'ai un fichier project.json qui fonctionne sans dépendance sur un autre projet, mais qui échoue. J'ai besoin de mettre un peu plus de temps pour arriver à une reproduction complète.

@jskeet Gotcha - pertinent : https://github.com/dotnet/cli/issues/2469 et le canal Slack est idéal pour le débogage en direct de project.json , venez avec des exemples et vous pouvez généralement commencer assez rapidement. Pour Slack, les canaux #general et #dotnet-core sont assez actifs, beaucoup de gens passent par là et aident la personne suivante.

Hmm... et maintenant ça marche. Il est possible qu'il s'agisse du même problème signalé par @NickCraver , et que je n'étais que dotnet restore -ing le mauvais projet pour le résoudre. Quoi qu'il en soit, j'exécute maintenant les tests Noda Time sur Linux, alors oui :) Merci à tous.

@piotrpMSFT concernant ma demande de pointeurs, j'ai trouvé tout ce dont j'avais besoin et j'ai commencé à travailler.

J'ai ajouté un PR initial pour le coureur dotnet-test-nunit à nunit/dotnet-test-nunit#1

Il explore et exécute des tests, mais a encore besoin de travail, de nettoyage et de test. Je rendrai le flux NuGet pour les artefacts de construction plus accessible si quelqu'un veut jouer avec.

Si quelqu'un a des idées sur la façon dont je peux déboguer le package NuGet lorsqu'il est chargé par Visual Studio, je pourrais avoir besoin d'aide. Jusqu'à présent, il ne s'exécute pas dans Visual Studio, mais cela pourrait être un problème de configuration.

@rprouse : Je serais heureux de voir comment Noda Time s'en sort, si cela peut être utile. Faites-moi savoir s'il y a quelque chose en particulier que vous aimeriez que je vérifie. Merci pour tout votre travail!

Il n'est pas encore prêt pour les heures de grande écoute, mais j'ai des tests NUnit .NET Core en cours d'exécution sur la console et dans Visual Studio. Il y a encore plusieurs problèmes à résoudre avant que je sorte une alpha, mais nous sommes maintenant beaucoup plus proches car le travail acharné est fait et c'est dans les détails.

Je publierai des détails sur la façon de tester avec la version CI après avoir résolu quelques problèmes. J'apprécierais si les gens pouvaient donner un coup de pied aux pneus et m'aider à trouver des problèmes.

Voici une capture d'écran.

@rprouse : Des progrès sur le build CI ? Vraiment envie de donner un coup de pied aux pneus ; Noda Time utilise un nombre _raisonnable_ de fonctionnalités NUnit, ce devrait donc être un bon début, de toute façon. J'ai vraiment hâte de pouvoir à nouveau exécuter des tests dans VS. (J'espère que NCrunch et CodeRush pour Roslyn commenceront également à le prendre en charge une fois qu'il sera sorti...)

@jskeet et d'autres qui souhaitent lancer les pneus et m'aider à tester avant de publier une alpha, j'ai mis à jour mon référentiel de démonstration sur une branche dotnet-test-nunit pour utiliser le nouveau coureur dotnet-test-nunit .

Veuillez signaler les problèmes dans le référentiel nunit/dotnet-test-nunit .

Les instructions de haut niveau sont ;

Mise à jour : dotnet-test-nunit est maintenant disponible en version alpha sur NuGet, sélectionnez Include prereleases . Vous n'avez plus besoin de mettre à jour votre fichier nuget.config .

dotnet-test-nunit est encore en cours de développement, vous devrez donc ajouter un fichier NuGet.Config à votre solution pour télécharger les packages NuGet à partir des flux NUnit CI NuGet.

Votre project.json dans votre projet de test devrait ressembler à ce qui suit ;

projet.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": { }
    }
}

Les lignes d'intérêt ici sont la dépendance sur dotnet-test-nunit . N'hésitez pas à utiliser la dernière version préliminaire qui se termine par -CI , c'est-à-dire la dernière version de la branche master. Notez que la dépendance NUnitWithDotNetCoreRC2 est le projet en cours de test.

J'ai ajouté "testRunner": "nunit" pour spécifier NUnit 3 comme adaptateur de test. J'ai également dû ajouter aux importations pour résoudre à la fois l'adaptateur de test et NUnit. Enfin, j'ai dû ajouter le runtimes . Si quelqu'un peut expliquer pourquoi je dois le faire, merci de me le faire savoir.

Vous pouvez maintenant exécuter vos tests à l'aide de Visual Studio Test Explorer ou en exécutant dotnet test partir de la ligne de commande.

# 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\

Avertissement

Comme je l'ai dit, c'est encore en cours de développement. dotnet-test-nunit version 3.3.0.39-CI répertoriée ci-dessus a un bogue où il lancera un ArgumentException lorsqu'il essaiera de sauvegarder le fichier TestResult.xml .

Notez également que la ligne de commande dotnet avale les lignes vides et ne fonctionne pas avec la couleur. La sortie du lanceur de test NUnit est en couleur, mais vous ne la verrez pas.

La partie « avalement de lignes blanches » est un bug connu : https://github.com/dotnet/cli/issues/2234

Merci pour le lien @jskeet , il semble que la couleur soit également un bug connu, dotnet/cli#1977

Le ArgumentException a été corrigé dans 3.3.0.49-CI . Je mettrai à jour mes instructions ci-dessus avec le correctif. Un autre problème en suspens est que je ne fournis pas actuellement le numéro de ligne des tests au runner, donc cliquer sur les tests dans Visual Studio Test Explorer ne vous amènera pas au code.

Ai-je raison de dire qu'il n'y a pas encore de support d'argument de ligne de commande, comme --where etc? (Je comprends parfaitement que ce n'est que le début - j'essaie juste de vérifier si c'est quelque chose que je devrais être capable de faire.)

J'ai essayé un project.json légèrement différent de vous. Je l'ai inclus ci-dessous textuellement, mais les différences importantes sont :

• Je souhaite également tester l'environnement d'exécution du bureau, j'ai donc deux cibles de framework
• J'utilise netcoreapp1.0 au lieu de netstandard1.5
• J'ai inclus la dépendance Microsoft.NETCore.App , avec "type"="platform"
• Regardez ma, pas de section d'exécution. (Peut-être en raison de certains des changements ci-dessus...)

{
  "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",
      }
    }
  }
}

Résultat:

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

Waouh. (En utilisant net451, j'obtiens un nombre de tests de 15646, ce à quoi je m'attendrais.)

Ensuite: essayer la même chose sur une machine Linux (où votre project.json ne fonctionnerait probablement pas sans modification car il ne mentionne pas Linux, mais le mien devrait, en théorie; cela dit, c'est une machine Ubuntu 16.04 donc son dotnet CLI est quelque peu emmêlé).

Hmm. Les tests sur Linux n'étaient pas terminés après 14 minutes de consommation de 100% de CPU. Faudra regarder de plus près ce qui se passe là-bas.

@jskeet

Ai-je raison de dire qu'il n'y a pas encore de support d'argument de ligne de commande, comme --where etc?

Mal testé, mais j'ai câblé --where et la plupart des paramètres de ligne de commande courants. J'ai toujours un problème, nunit/dotnet-test-nunit#4 pour vérifier qu'ils sont tous câblés correctement et qu'ils fonctionnent et ajouter tout ce qui pourrait manquer. Jusqu'à présent, je n'en ai pas testé beaucoup, mais j'en ai utilisé quelques-uns en les ajoutant à la fin de la commande dotnet . J'ai encore besoin de comprendre exactement comment cela fonctionne. Par exemple, l'option de ligne de commande --debug fonctionnait correctement à partir de la solution dotnet-test-nunit , mais elle renvoie dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" lorsque je l'exécute à partir de ma solution de test. Je ne sais pas non plus comment enchaîner la ligne de commande d'aide à la nôtre pour montrer ce qui est pris en charge.

En attendant, vous pouvez jeter un œil à https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs pour voir quelles options de ligne de commande je pense être pris en charge :sourire:

Ah, oui - il semble que dotnet test n'ait pas la même facilité que dotnet run pour séparer les arguments du framework de test des arguments vers dotnet test lui-même. j'avais essayé

dotnet test -- --help

et

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

Juste en utilisant

dotnet test --where=cat!=Slow

fonctionne bien. Fera une demande de fonctionnalité pour cela - c'est bien de pouvoir être complètement sans ambiguïté.

Le clic sur les tests et la navigation vers le code sont désormais corrigés dans 3.3.0.60-CI .

Il y a encore deux problèmes hautement prioritaires, alors je prévois de faire une version alpha. À ce stade, je fermerai ce problème et suivrai tout dans le nouveau référentiel. Les deux problèmes sont ;

• [x] nunit/dotnet-test-nunit#22 Ajouter des messages et des traces de pile aux tests ayant échoué
• [x] nunit/dotnet-test-nunit#12 TestContext.WriteLine n'apparaît pas dans le résumé du test TestExplorer

Pour info, j'ai réexécuté les tests Noda Time aujourd'hui sur ma machine Ubuntu, et ils se sont terminés après environ 15 minutes. On dirait qu'ils fonctionnent tous environ 5 à 6 fois plus lentement sur mon Linux i5 que sur mon Win10 i7. Je ne sais pas combien cela a à voir avec le CPU et combien cela a à voir avec JIT - et c'est définitivement hors de la portée de NUnit :)

@jskeet merci pour la mise à jour, c'est une bonne nouvelle. Aviez-vous besoin de liaisons mono pour les tests Linux comme indiqué dans nunit/dotnet-test-nunit#9 ?

Pour tous ceux qui testent, le dernier bon package NuGet est 3.3.0.69-CI , veuillez tester avec cela. Il n'y a maintenant aucun problème en suspens qui, à mon avis, soit suffisamment sérieux pour bloquer une version. Si aucun n'est signalé cette semaine, je créerai probablement une version alpha plus tard cette semaine ou au début de la semaine prochaine. Une fois cela fait, je fermerai ce problème et les discussions/problèmes futurs pourront continuer dans le dotnet-test-nunit .

Teste maintenant ou tais-toi pour toujours :sourire:

@rprouse : je n'ai pas essayé de l'exécuter sur Mono - uniquement .NET Core sur Linux. Cela a bien fonctionné avec le project.json exact ci-dessus.

Donnera un tourbillon au 69-CI...

Une différence que j'ai remarquée entre cela et le programme d'exécution de l'application de la console est que la version "dotnet test" semble inclure le temps passé à rechercher des tests dans la durée globale, alors que la commande "dotnet run" que j'utilisais avec NUnitLite ne l'a pas fait. . Dans Noda Time, cela signifie que si je cours avec --where=cat==Foo (il n'y a pas de tels tests dans cette catégorie), "dotnet test" rapporte une durée de 14s alors que "dotnet run" rapporte une durée de 0,01s - malgré les deux prenant à peu près le même temps réel écoulé.

Est-ce délibéré ? Le comportement ne me dérange certainement pas, mais cela vaut peut-être la peine de le noter quelque part pour éviter que les gens pensent que c'est en fait plus lent.

@jskeet c'est un bon constat, c'est bien le cas. Parce que nous n'avons pas le moteur NUnit complet pour exécuter les tests, le code est plus simpliste, mais je pourrais peut-être démarrer l'horloge sur le premier événement de test démarré plutôt que d'envelopper l'exécution du test. Je vais entrer un problème.

J'ai publié une version alpha de dotnet-test-nunit sur GitHub à l' adresse https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 , vous n'avez donc plus besoin de changer votre NuGet.config et utilisez les versions CI.

Maintenant que j'ai une sortie alpha, je vais clore ce sujet. Aidez-moi à tester l'alpha et signalez tout problème sur https://github.com/nunit/dotnet-test-nunit/issues. La version finale est prévue pour la fin du mois avec la version NUnit 3.4. Je publierai des versions alpha et bêta mises à jour en fonction des problèmes rencontrés.

J'ai mis à jour la documentation dans le fichier readme pour dotnet-test-nunit . Je vais garder ça à jour.

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

Comme je l'ai noté précédemment, vous n'avez pas besoin de spécifier les runtimes si vous utilisez "type": "platform" pour la dépendance "Microsoft.NETCore.App" . Compte tenu de la documentation xUnit, je pense que c'est l'approche préférée.

J'ai actuellement une pull request qui passe par Travis - si cela passe au vert, Noda Time en dépendra, donc cela devrait lui donner _quelque_ utilisation. Bravo, monsieur...

Un inconvénient que j'ai remarqué tout à l'heure - cela signifie que je ne peux plus facilement tester avec Mono sur Linux. Je crois que ce n'est pas un problème NUnit, c'est essentiellement une manifestation de https://github.com/dotnet/cli/issues/3073 mais pour NUnit. J'espère toujours que cela finira par être corrigé; pour le moment je vais désactiver mes tests mono dans Travis, avec un peu de réticence. ( dotnet test est définitivement l'avenir.)