Nunit: Joindre des fichiers au résultat du test

La méthode que vous mentionnez fait partie de la classe TestContext dans le framework de test de Microsoft. NUnit a également une classe du même nom, mais elle n'a aucune relation avec la classe MsTest et n'a pas une telle méthode. Il n'y a aucune fonction dans NUnit pour joindre des fichiers à la sortie.

Merci Charly.
Mais la méthode AddResultFile s'ajoutera-t-elle à NUnit à l'avenir ?
Cette méthode vraiment utile.

Il n'y a aucun plan pour cela pour le moment. Si vous souhaitez transformer ce problème en une demande pour une telle fonctionnalité, nous pouvons le faire et le rouvrir.

Si c'est le cas, vous devriez expliquer plus en détail comment cela fonctionnerait. Comment les fichiers sont-ils créés, où sont-ils stockés, etc. Demandez-vous à NUnit de créer réellement les fichiers ou simplement de conserver une référence à ceux-ci ?

Bien sûr, nous devrions accepter l'idée, la prioriser et la programmer pour une sortie.

Merci pour ta réponse Charly.
Ce serait formidable si cette méthode était ajoutée à NUnit.
cela fonctionnerait exactement comme la méthode AddResultFile de la classe TestContext dans le cadre de test de Microsoft.
quelque chose comme lier le résultat du test (fichier résultat de test html ou capture d'écran) à la sortie de test dans Test Explorer dans VS. Vous pouvez voir la capture d'écran ci-dessous.

Merci pour l'idée. Je vais rouvrir ça.

Pour aller plus loin, cependant, nous devrons comprendre comment cela fonctionne pour NUnit lui-même, pas seulement pour l'adaptateur. Je marque cela comme une idée, c'est ce que nous appelons quelque chose qui n'est pas assez bien défini pour être considéré comme une fonctionnalité future. Peut-être que d'autres personnes feront des suggestions.

Choses que nous devons considérer:

• À quoi cela ressemblerait-il dans le résultat XML
• Pouvons-nous emballer tout cela de manière à ce que le résultat et les pièces jointes soient conservés ensemble ?
• Qu'est-ce que la console NUnit en ferait, le cas échéant.
• L'interface graphique NUnit l'afficherait-elle d'une manière ou d'une autre

Cette fonctionnalité est indispensable.
Nous effectuons nos tests de comportement automatisés avec NUnit et Selenium. Si un test échoue, nous adorons joindre une capture d'écran du navigateur dans le résultat du test : c'est une aide précieuse pour corriger le test.
Pour ce faire, nous avons dû utiliser le framework de test de Microsoft, mais il n'est pas aussi puissant que NUnit (attribut au niveau de l'assembly ou de la classe, classe de test générique...). Nous attendons donc avec impatience cette fonctionnalité dans NUnit.

Je change cela en une fonctionnalité nécessitant un design, ce qui est plus solide qu'une idée. Nous devons encore résoudre les questions énumérées dans mon commentaire précédent.

Je suppose qu'il s'agit soit de sérialiser le fichier dans le XML, soit de conserver un répertoire référencé à côté. L'un conduit à un vaste xml, une lenteur générale et des fichiers nécessitant un interpréteur spécifique, l'autre conduit à la possibilité de séparer les fichiers des résultats et de rompre les références.

Quel est le moindre des maux ? J'ai l'impression qu'avec le premier, la douleur l'emportera sur les avantages de tout garder dans l'emballage - et avoir des liens relatifs "espérons-le disponibles" suffira.

• Qu'est-ce que la console NUnit en ferait, le cas échéant.
• L'interface graphique NUnit l'afficherait-elle d'une manière ou d'une autre

Pour l'interface graphique, quelque chose comme l'interface ci-dessus est assez joli, juste des hyperliens vers le fichier joint. La console, imo, doit informer l'utilisateur dans le message d'échec du test qu'un fichier est disponible et son emplacement.

J'imagine que cela nécessitera que quelqu'un soumette un PR, une fois le design élaboré - @fredgate , ça vous intéresse ? ??

Nous devrions regarder comment MSTest stocke les fichiers. Je m'attends à ce que l'extension Visual Studio nécessite un lien vers le fichier sur le lecteur.

On dirait qu'une référence dans le XML est la voie à suivre. Pour NUnit, l'emplacement initial logique est le répertoire de travail, où se trouve le XML par défaut. Cela résout mes deux premiers points ci-dessus.

Répondre à mes autres points :

• Je suppose que la console ne ferait que répertorier les pièces jointes avec le chemin, tout comme elle le fait pour les résultats.
• L'interface graphique peut avoir une sorte de menu ou de panneau pour lister les pièces jointes. Il pourrait les afficher à condition qu'une application par défaut ait été définie pour le type de fichier particulier.

Cela semble être une bonne fonctionnalité, que je pencherais vers une priorité normale.

@rprouse Vous

Que doit inclure un élément de pièce jointe en termes d'attributs et d'éléments ? Quelque chose comme ça?

<attachments>
    <attachment  description="Final screen shot">ScreenShot.jpg</attachment>
    ...
</attachments>

Je suppose que c'est un enfant du test qui l'a produit, nous avons donc cette information. Les utilisateurs peuvent vouloir inclure plusieurs captures d'écran, d'où la description. Rien d'autre?

Quelle est la syntaxe pour attacher quelque chose ? Doit-on utiliser TestContext ? Devrait-il y avoir un moyen de l'associer à une assertion afin que la pièce jointe soit automatiquement créée en cas d'échec ?

Est-ce que quelqu'un veut écrire une spécification pour cela?

Cela semble être une bonne fonctionnalité, que je pencherais vers une priorité normale.

??

@rprouse Vous

Non, je n'ai jamais utilisé de pièces jointes. J'aime votre format XML. Personnellement, je pense que nous devrions commencer par ajouter des pièces jointes à partir du TestContext car c'est la route la plus simple. Nous pouvons ensuite évaluer si nous voulons étendre cela aux Asserts.

Alors TestContext.CurrentContext.AddAttachment ?

Avec des surcharges pour (string path) et (string path, string description) ?

Peut-être avons-nous déjà une spécification !

Veuillez augmenter la priorité de cette fonctionnalité. Il serait très utile pour notre résumé des résultats de test de joindre des captures d'écran de l'interface utilisateur. Ces pièces jointes seraient-elles disponibles dans le résultat de la génération dans VSTS (Visual Studio Team Services) ?
Merci beaucoup Charly

Je pense que c'est une bonne fonctionnalité et je publierai les pièces jointes en tant qu'artefacts de construction dans TeamCity

Je l'ai élevé à la priorité normale puisque @rprouse l' avait déjà suggéré. Notez cependant que les éléments de priorité faible et normale doivent parfois attendre que quelqu'un soit inspiré pour les implémenter - soit un commiter NUnit, soit un contributeur. C'est plus une décision personnelle qu'une décision d'équipe quant au moment où cela sera fait.

J'espère que personne n'a oublié cela. Ce serait une fonctionnalité très utile.

Je pense que les commentaires précédents ont résolu tous les problèmes de conception, j'enlève donc l'étiquette de conception et j'ajoute le problème de mise en œuvre au Backlog.

Ce n'est pas tant que nous avons oublié cela que que nous avons un grand nombre de choses en cours. Comme je l'ai mentionné dans un commentaire précédent, les éléments prioritaires normaux comme celui-ci ne sont pas planifiés dans le cadre de notre planification de publication. C'est à un membre de l'équipe ou à un contributeur extérieur de s'intéresser suffisamment pour s'en charger. Espérons que l'ajouter à l'arriéré motivera quelqu'un à intervenir. Selon vos compétences, cela pourrait être vous ! ??

super fonctionnalité ! serait très apprécié. j'espère que quelqu'un implémentera cela bientôt

Je viens de faire un PR pour la fonctionnalité de framework requise pour implémenter cela, dans #2152. Étant donné que quelques personnes suivent ce problème, je prévois de convertir ce problème en support Epic et track runner, une fois que nous aurons décidé quoi faire là-bas.

Voici mes réflexions :

Adaptateur VS
Il s'agit d'une fonctionnalité dont dispose MSTest, de sorte que l'infrastructure de l'adaptateur VS dispose déjà d'une fonctionnalité pour afficher les fichiers joints. Il suffit de trouver comment le brancher. 🙂

Console/NUnitLite
Je suis mitigé ici. Avec les tests d'erreur/d'avertissement, il est logique d'afficher le chemin d'accès/la description d'une pièce jointe avec le résultat. Qu'en est-il des pièces jointes aux tests réussis ? Devrions-nous avoir une sortie « Informations » pour les afficher ? Ainsi, les coureurs de console auraient trois types de sortie - Information/Avertissements/Erreurs ?

GUI/Xamarin
Les deux devraient éventuellement soutenir cela, mais je ne pense pas que ce soit une priorité élevée. Je créerai des problèmes, mais je ne les attacherai pas à cet Epic - ils peuvent être effectués lorsque la demande/le temps le permet.

TeamCity
@NikolayPianikov - vous avez dit que cela vous intéressait. Cela vaut peut-être la peine que vous suiviez #2152. ??

Des réflexions sur tout ce qui précède ? @nunit/framework-team ? Je ferai des questions individuelles une fois que nous aurons décidé des prochaines étapes.

@ChrisMaddock Les problèmes peuvent également être des problèmes de conception, vous pouvez donc en faire un qui dit "Découvrez comment prendre en charge les pièces jointes dans l'

Pour le coureur de console, nous ne montrons actuellement pas tous les tests, bien que cela puisse être fait. Tout rapport détaillé peut être géré par une extension ou une transformation XSL personnalisée. Ce dernier serait trivial à mettre en œuvre pour quiconque est prêt à faire du codage XSL. Il pourrait s'agir d'une transformation contribuée.

NUnitLite est délicat, car nous voulons le garder très léger. Cependant, on suppose que les utilisateurs nommeront leurs pièces jointes de manière intelligente et les mettront toutes dans le même répertoire, elles devraient donc être assez faciles à trouver. En fait, cela fonctionne aussi bien pour le coureur de console
Je pense que la chose naturelle pour l'interface graphique est d'afficher le nom et la description des pièces jointes ainsi que tout le reste concernant le résultat du test. Nous pourrions en faire un lien si l'utilisateur a installé une application appropriée qui ouvrira le fichier.

Une fois que nous avons des pièces jointes, je pense qu'il est très facile de les ajouter aux résultats que nous transmettons à Visual Studio depuis l'adaptateur.

J'ai créé https://github.com/nunit/docs/issues/197 et https://github.com/nuni/nunit3-vs-adapter/issues/332 pour couvrir les prochaines étapes.

En ce qui concerne la prise en charge des coureurs - si les seuls appels actuels pour cela sont l'intégration avec l'adaptateur VS, je suis enclin à l'implémenter là-bas, pour l'instant. C'est une fonctionnalité qui s'adapte mieux aux coureurs graphiques, puis cli - et d'autres supports de coureurs peuvent toujours être ajoutés à l'avenir, si les gens en ont besoin.

@ChrisMaddock J'aimerais voir la prise en charge des pièces jointes par le coureur de la console.

@kdubau - timing parfait ! 😄 Dans ce cas, à quoi voudriez-vous qu'il ressemble ? Quel serait votre cas d'utilisation ?

Je pourrais imaginer ajouter un bloc de texte « pièces jointes » pour tester les échecs/avertissements, lister la description et le chemin du fichier. L'une des raisons pour lesquelles je discutais de ne pas le faire est que je n'étais pas convaincu que de nombreux utilisateurs voudraient copier/coller un chemin de fichier hors de leur shell, pour trouver le fichier respectif. Seriez-vous en désaccord?

L'autre problème auquel il faut penser est que la console n'affiche actuellement que les tests échoués/avertis, et pas tous les tests. Devrions-nous créer une troisième liste de résultats (« Information » ?) qui montre tous les tests réussis avec pièces jointes ?

Peut-être que ce serait bien que le gestionnaire de console n'affiche que les pièces jointes pour les tests échoués, car c'est peut-être tout ce qui est intéressant dans une exécution de console. J'imagine des fichiers journaux pertinents pour les échecs ici, et autres.

@kdubau Plutôt que de le décrire ici, je vous suggère de créer un nouveau problème dans le repo nunit-console.

@ChrisMaddock @CharliePoole J'ai peut-être mal compris le contexte ici. Je ne suis intéressé que par le fait que les pièces jointes soient référencées dans le XML de sortie - pas besoin d'afficher réellement les informations sur les pièces jointes dans la sortie de la console. Mon cas d'utilisation est que mon système CI (Visual Studio Team Services) soit capable de télécharger les pièces jointes répertoriées dans le XML en tant qu'artefacts de construction (il suffirait donc d'une référence au fichier sur le disque local).

Je craignais que l'exécution de tests via le programme d'exécution de la console n'ait pas les pièces jointes dans le XML, mais en lisant davantage, je ne pense pas que ce soit la question. Corrigez-moi si j'ai tort, s'il-vous plait :)

@kdubau - Vous avez raison. 🙂 #2152 vient d'être fusionné, qui prend en charge les pièces jointes dans les résultats xml. Si tout se passe comme prévu, cela fera partie de NUnit 3.7, publié la semaine prochaine.

Bon... si nous avons besoin de "support" dans la console, cela signifierait faire quelque chose de plus que simplement sauvegarder le XML qui vient du framework. Dans le cas de l'adaptateur nunit3, je suppose que @ChrisMaddock définit ce que cela signifiera.

Salut les amis, ce travail est-il terminé ou en attente ? Je n'ai pas pu trouver de problèmes ouverts ou de relations publiques liées à cela.

Je m'excuse si quelque chose m'échappe mais que mes pièces jointes de test n'apparaissent toujours pas dans l'explorateur de test VS comme je m'y attendais. J'utilise NUnit3TestAdapter 3.8.0 de NuGet et l'API TestContext.AddTestAttachement(file) mais je ne vois pas les pièces jointes dans l'explorateur de tests. J'attends quelque chose comme ça :

Mes attentes sont-elles fausses ?

@kdubau - Non, cela devrait être publié dans NUnit v3.7 et NUnit3TestAdapter 3.8. Voir https://github.com/nuni/nunit3-vs-adapter/issues/332 pour la mise en œuvre. Ce problème reste ouvert car je n'ai toujours pas le temps d'ajouter les deux phrases de documentation requises...

Si cela ne fonctionne pas, j'exécuterais d'abord vos tests dans la console NUnit - et je verrais si votre pièce jointe est correctement enregistrée dans le fichier XML des résultats. Si ce n'est pas le cas, ouvrez un problème dans ce référentiel, si c'est le cas, ouvrez un problème dans le référentiel de l'adaptateur, et nous pourrons approfondir nos recherches. ??

@ChrisMaddock d' accord, problème créé https://github.com/nunit/nunit3-vs-adapter/issues/373

Grâce à la motivation de @kdubau , j'ai enfin documenté cette fonctionnalité et je peux clôturer cet Epic. ??