Nunit: Projet ou assemblage AssertionHelper distinct

Je ne savais même pas que nous avions un AssertionHelper :fearful:

Je considère cela comme un vote pour la suppression. :-)

Je ne savais pas qu'on en avait un non plus :(

Que fait-il ou qu'est-il censé faire ?

Votre classe de test en hérite, vous donnant une syntaxe pour les assertions qui ne nécessite pas de nom de classe statique. Voir, par exemple, https://github.com/nunit/nunit-csharp-samples/blob/master/syntax/AssertSyntaxTests.cs et rechercher « Expect »

Comme je l'ai commenté dans #1211, il n'a pas été tenu à jour avec les dernières fonctionnalités de la syntaxe Assert.That. Idéalement, si nous le gardons, je pense qu'il devrait être dérivé dans un projet séparé et maintenu par les personnes qui l'utilisent réellement.

Comme je l'ai commenté dans #1211, il n'a pas été tenu à jour avec les dernières fonctionnalités de la syntaxe Assert.That. Idéalement, si nous le gardons, je pense qu'il devrait être dérivé dans un projet séparé et maintenu par les personnes qui l'utilisent réellement.

Je suis d'accord. De combien de manières voulons-nous soutenir l'écriture des assertions ? Garder Assume synchronisé avec Assert est déjà assez difficile :smile:

Dans de nombreux cas, vous pouvez utiliser "à l'aide de static nunit.framework.Assert" à la place, je pense. Donc ça ne me dérange pas qu'il soit supprimé.

D'accord avec ce qui précède, je ne savais pas non plus que cela existait.
Retirez-le ou déplacez-le juste pour le garder en sécurité.

Pourrions-nous extraire l'assistant dans un package nuget - il suffit d'en créer un manuellement pour le moment car il s'agit d'une sorte de sonde, puis de voir combien le téléchargeraient ?
S'il obtient, disons, moins de 1000 sur une période de 6 mois, alors nous le laissons tomber.

Je l'utilise fréquemment dans mes projets, mais je suis fortement en faveur de sa suppression progressive de NUnit (soit par suppression complète, soit par passage à un package subsidiaire). Je peux facilement refactoriser mes projets pour m'en passer ; il suffit de rechercher et de remplacer pour Expect (et le compilateur s'occupera du reste en signalant les erreurs, le cas échéant).

On dirait une fonctionnalité. :-)

Nous pourrions le faire de manière ad hoc, mais j'aimerais l'utiliser comme pilote pour quelque chose qui était dans la conception originale de NUnit 3. Il y avait cette idée que vous pouviez superposer des syntaxes supplémentaires au-dessus de l'assemblage du framework. Celui-ci est assez simple et nous pourrions l'utiliser pour proposer une conception de syntaxes alternatives ajoutées à NUnit. Cela signifierait que cela deviendrait un projet et un téléchargement distincts, comme le suggère Terje.

En soi, il s'agit d'une fonctionnalité de faible priorité, mais nous pourrions la pousser vers l'avant afin de casser la conception nécessaire pour la superposer au cadre. Cela devrait être assez simple à faire.

@MSK61 Alternativement, êtes-vous intéressé à aider à le maintenir si nous le déplaçons dans un package séparé ?

PR #1250 a maintenant isolé l'utilisation d'AssertionHelper dans nos propres tests. Il n'est plus utilisé du tout sauf dans AssertionHelperTests. Cela nous permet de le séparer ou de le retirer facilement.

J'ai marqué ce problème « conception du statut » car nous devons réellement décider ce que nous voulons faire avant de continuer. Voici mon avis...

Je ne pense pas que nous devrions l'éliminer parce qu'au moins certaines personnes l'utilisent. Le fait que ce soit un petit nombre n'a pas tellement d'importance pour moi. Nous sommes passés à la version 3.0 sans décider que c'était un changement décisif, donc je dirais qu'il est trop tard pour le faire maintenant. NUnit a une longue tradition de continuer à soutenir les utilisateurs bien au-delà de ce que font la plupart des projets commerciaux. J'aimerais garder la tradition.

De plus, je pense que décider comment gérer AssertionHelper est une chose utile à faire pour nous. La conception de NUnit 3.0 nécessitait à l'origine des couches syntaxiques alternatives au-dessus du noyau du framework. Nous avons mis cela de côté pour la version initiale, mais j'aimerais y revenir. AssertionHelper est relativement trivial - deux fichiers plus un fichier de test - et nous pouvons nous concentrer sur l'architecture souhaitée pour les frontaux syntaxiques dans le cadre de cette opération.

[Au cas où vous n'auriez pas vu les documents de conception depuis un certain temps, les adaptateurs syntaxiques pour le framework étaient destinés à servir à deux fins : des syntaxes alternatives pour l'utilisation de NUnit et des frontaux de langage alternatifs. Les applications tierces existantes dans chaque catégorie sont shouldly et fsunit. Nous avions prévu de fournir un moyen standard de créer des adaptateurs de syntaxe au-dessus du framework, de l'utiliser nous-mêmes et de le proposer aux développeurs tiers afin d'encourager l'utilisation de NUnit. Comme indiqué ci-dessus, c'était un trop gros défi pour entrer dans la version 3.0, nous ne l'avons donc pas implémenté.]

Retour à AssertionHelper... voici quelques options...

• Gardez-le dans le cadre de NUnit
  
  
  
  • Espace de noms séparé (je n'aime pas ça car cela casse la compatibilité)
  
  
  • Assemblage séparé
  
  
• Faire un nouveau dépôt
  
  
  
  • Code source uniquement - les gens peuvent l'inclure dans leurs propres projets
  
  
  • Distribuer des binaires
  
  
  • Faites les deux (similaire à ce que fait fsUnit - c'est l'option que je préfère)
  
  

Si notre direction inclut la distribution de binaires, nous devons décider quelles versions prendre en charge. Cela pourrait être toutes nos versions existantes, bien sûr, mais je serais d'accord pour le limiter à .NET 4.5 et Portable. Nous pourrions en ajouter plus s'il s'agissait d'une demande. Les utilisateurs ne nous disent jamais si nous en faisons trop, mais ils s'expriment généralement si nous en faisons trop peu. :-)

Je préférerais passer à l'utilisation de configurations distinctes plutôt que de projets distincts pour chaque type de build. Cela limiterait le nombre de projets que nous devons définir et nous pourrions utiliser la compilation conditionnelle au besoin. AssertionHelper inclut quelques fonctionnalités qui doivent être exclues de la version Portable.

Veuillez ajouter vos commentaires ici. Quand il semble que nous ayons un consensus, j'irai de l'avant.

Cela semble être un excellent moyen de « déprécier » une fonctionnalité, en la déplaçant vers un référentiel séparé et des packages de compléments. Il s'agit alors clairement d'un problème de maintenance distinct et peut être mis à jour juste lorsque de nouvelles fonctionnalités sont spécifiquement demandées. (Ce qui, sur la base de ce sujet, peut être rare !) Il serait également beaucoup plus facile à sortir que les autres versions de framework figurant sur la liste, ce qui créerait potentiellement des problèmes de maintenance.

Pour relancer le débat...

Je pense qu'un ensemble séparé de dépôt, d'assemblage et de nuget semble idéal. Cela nécessiterait une nouvelle référence de projet pour les utilisateurs ("rupture de changement") - mais semble acceptable, uniquement similaire à ce qui vient d'être requis pour .NET 2.0 avec NUnit.Linq.

Espace de noms séparé (je n'aime pas ça car cela casse la compatibilité)

D'accord, l'espace de noms actuel devrait être maintenu, ce qui est dommage s'il s'agit d'un complément, mais les problèmes de compatibilité l'emporteraient sur la " laideur " à mon avis !

Cela pourrait être toutes nos versions existantes, bien sûr, mais je serais d'accord pour le limiter à .NET 4.5 et Portable.

Pour les fonctionnalités « héritées », serait-il judicieux d'inclure/ne faire que les anciennes cibles ?

Je préférerais passer à l'utilisation de configurations distinctes plutôt que de projets distincts pour chaque type de build. Cela limiterait le nombre de projets que nous devons définir et nous pourrions utiliser la compilation conditionnelle au besoin. AssertionHelper inclut quelques fonctionnalités qui doivent être exclues de la version Portable.

Je suppose que vous entendez par là un seul projet VS et que vous le ciblez plutôt sur différents runtimes au moment de la compilation, c'est-à-dire via Cake? Si oui, je suis d'accord.

Cela ne sera-t-il pas encore étroitement lié au cadre en raison de son besoin de diverses affirmations sous les couvertures ? Si tel est le cas, un assembly séparé serait lié à une version spécifique du framework et devrait être publié de manière synchronisée. Si tel est le cas, n'est-il pas plus facile de le laisser où il est ?

J'ai supposé qu'il faudrait quelque chose d'équivalent à nunit.engine.api au niveau du framework? Je ne savais pas si c'était l'idée d'"adaptateur syntaxique" à laquelle @CharliePoole faisait référence.

(Je n'ai pas beaucoup d'aperçu du code ici pour savoir à quel point c'est possible !)

Je suis sûr que nous pouvons le comprendre avec une sorte d'indirection comme le moteur
utilise, je me demande juste si cela en vaut la peine :-)

Eh bien, c'est une faible priorité, donc ça ne vaut pas une tonne d'efforts. :-) Quelque chose à considérer lorsque nous décidons comment le faire.

@ChrisMaddock J'ai utilisé les priorités légèrement différemment pour les problèmes qui font partie d'Epics. Je note ces bas qui peuvent finir par être facultatifs en ce qui concerne l'Epic.

@rprouse Je pense qu'une sorte d'indirection est possible, mais cela le rendrait dépendant d'une refactorisation beaucoup plus ambitieuse du framework, similaire à ce que les gars de xunit ont fait. J'y ai pensé mais je n'ai pas créé de problème au-delà de la simple séparation des affirmations. C'est peut-être du matériel 4.0. :-)

@ChrisMaddock Oui... Je suggérais que nous ayons des configurations telles que "Portable - Debug", "Desktop - Release", etc. Ou peut-être que nous pourrions utiliser les nouvelles définitions netstandard à la place.

Pour une tâche à faible coût comme celle-ci, mon premier choix serait de le laisser reposer un moment. Mon deuxième choix, si quelqu'un meurt d'envie de tenter le coup, serait de faire un assemblage séparé au sein de la solution existante. Mais vraiment, je préfère le voir attendre la fin de l'épopée.

@rprouse J'allais publier mon ordre proposé de faire les sous-problèmes sur l'Epic mais j'attendais d'abord vos commentaires à ce sujet. Dois-je simplement aller de l'avant et poster?

@CharliePoole, allez-y et publiez. Nous en avons suffisamment parlé pour être tous les deux sur la même longueur d'onde.

En y repensant après une longue absence, voici mes réflexions du moment...

1. Nous devrions __vraiment__ nous débarrasser de cela. Cela donne une autre façon de faire Asserts, mais ne remplace pas Assume ou Warn, c'est donc une implémentation partielle, que nous ne voulons pas terminer.

2. Mes inquiétudes concernant la modification de l'espace de noms étaient peut-être injustifiées. Étant donné que vous ne pouvez l'utiliser qu'en héritant d'AssertionHelper, vous n'avez vraiment besoin que de modifier la ligne de déclaration de votre classe de test.

3. Nous devons décider si nous voulons déplacer cela progressivement ou dans un grand changement. Est-il préférable que les utilisateurs subissent plusieurs changements ou un seul changement, même s'il est légèrement plus important ?

Un gros changement sonne bien.

Envisagiez-vous toujours un package séparé, au moins pour quelques versions pour voir à quoi ressemble l'utilisation ?

Nous l'avons ajouté au backlog car nous ne le marquons que comme obsolète pour le moment.

Si nous allons de l'avant et supprimons cela, les dépôts d'échantillons devront également être mis à jour. Ils utilisent AssertionHelper.

Nous pouvons le faire à l'avance. J'ai ajouté des problèmes pour C#, C++ et VB. Les exemples F# ne l'utilisent pas.

Je laisse juste mon 2c ici :

Pour ma part, je suis un grand fan de la syntaxe Expect fournie par AssertionHelper, en particulier lorsque l'on doit gérer des projets Javascript aux côtés de .NET et que la syntaxe reste familière entre les deux.

Il semble que l'intérêt pour AssertionHelper soit du domaine de l'ésotérisme -- donc je me porte volontaire pour faire partie de la maintenance d'AssertionHelper s'il doit être publié en tant que dépôt séparé. Une idée serait de publier également des packages nuget de même version (c'est-à-dire que nunit xyz a un nunit.assertionhelper xyz correspondant qui dépend spécifiquement de nunit xyz) en parallèle avec les versions nunit. Encore une fois, je me porte volontaire pour en faire partie.

Une idée pourrait également être de fournir Expect en tant que statique qui peut être importée de manière statique, afin que les appareils de test n'aient pas à hériter d'AssertionHelper - ce qui rend certains autres scénarios plus faciles à gérer. En fait, cela sonne (pour moi) comme une façon relativement propre de faire la pause. Les pensées?

Depuis que j'ai découvert AssertionHelper il y a environ 6 ou 8 mois, j'ai en fait migré des tests vers cette syntaxe, chaque fois que je rencontre des tests utilisant la syntaxe statique Assert, donc je suis en fait assez investi pour garder cela en vie, si possible.

@fluffynuts C'est génial si vous voulez devenir le mainteneur d'AssertionHelper et je serais heureux de vous aider à le faire. Il est un peu plus difficile de vous faire __partir__ de le maintenir si l'équipe de base NUnit le supprime de NUnit.

@ChrisMaddock @jnm2 Je pense que vos sont un peu ambigus. Êtes-vous tous favorables à l'abandon de AssertionHelper (pour lequel je pense que vous avez tous les deux voté) et à ce que quelqu'un d'autre prenne le relais ? Ou êtes-vous pour @fluffynuts demande que nous le

@CharliePoole eh bien, si l'équipe de base NUnit est using static et signifierait que les appareils n'auraient plus à hériter d'AssertionHelper.

Si je devais le faire, je serais intéressé par une sorte de notification de la part de l'équipe principale NUnit d'une version à venir, de sorte que je puisse essayer de publier un package nuget de même version en fonction de la nouvelle version dès que possible après la version NUnit. Je serais heureux de faire le travail requis, tant que tout le monde dans l'équipe de base NUnit est d'accord avec cela. Évidemment, je ferais alors toutes les requêtes contre la syntaxe Expect, mais j'aurais également l'énorme avantage de commencer avec une base de code riche et fonctionnelle, sans essayer de faire un Expect-a-like.

Les pensées?

Donnons aux gars une chance de répondre. J'ai indiqué la direction dans laquelle je __pensais__ que nous avions décidé d'aller, mais il est toujours possible - en particulier en travaillant à distance - d'avoir des compréhensions complètement opposées à partir de la même discussion.

En ce qui concerne using static je ne sais pas comment cela vous donnerait l'un des avantages d'AssertionHelper __except__ pour le verbe Expect . Comment géreriez-vous les contraintes ?

Pour être honnête, je n'ai pas beaucoup réfléchi à l'idée au-delà de "ce serait
cool si je pouvais obtenir la syntaxe Expect sans héritage". Je vais lui donner un
regarde de plus près demain (:

Le 31 mai 2017 à 21h34, "CharliePoole" [email protected] a écrit :

Donnons aux gars une chance de répondre. j'ai déclaré le
direction que je pensais que nous avions décidé d'aller, mais c'est toujours possible

• surtout travailler à distance - avoir des compréhensions complètement opposées
  de la même discussion.

En ce qui concerne l'utilisation de statique, je ne sais pas comment cela vous donnerait l'un des
avantages d'AssertionHelper à l' exception du verbe Attendre. Comment voudriez-vous
faire face aux contraintes ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/nuni/nunit/issues/1212#issuecomment-305293434 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AEc_nD4YNgRCDjCR8yYjkbXlIJiJd6S9ks5r_cDIgaJpZM4HL8Bi
.

Ce que je voulais voir, c'était l'AssertionHelper séparé du framework - nous avons beaucoup à maintenir ici et une grande API, et, à mon avis, c'est la bonne branche à couper. S'il y a un intérêt (ce qui semble provenir d'au moins un utilisateur !) - un package NuGet séparé qui dépend du package de framework me semble une solution idéale.

D'après ce que j'ai compris, l'une des motivations de la dépréciation, plutôt que de la suppression directe, dont nous avons également discuté, était d'avoir une bonne idée de l'utilisation - et @fluffynuts a présenté exactement le genre de proposition dont nous avons parlé - pour maintenir AssertionHelper en tant que emballer. D'où mon 👍 !

Je serais heureux qu'il reste dans l' organisation NUnit, séparé du framework. Cela dépendrait de la volonté de tout futur mainteneur, bien sûr - je ne suis pas volontaire pour m'en occuper ! Si, pour une raison quelconque, la maintenance devait tomber, je pouvais le voir se dérouler de la même manière que les versions SL et CF - non maintenues, mais archivées et prêtes pour tous ceux qui souhaitaient les récupérer.

@ChrisMaddock Merci pour la clarification. Tout ce dont je me souvenais, c'est que j'en avais fait un projet séparé mais que j'avais annulé ce changement parce que quelqu'un (peut-être pas vous) voulait que nous le gardions ou le tuions complètement.

Mes pensées sont les mêmes que celles de
De plus, cela change la donne si nous ne connaissons personne qui soit motivé à investir, et que quelqu'un se présente. Même si je pense qu'il ne faut plus y consacrer de temps, je ne voterai jamais pour empêcher un parti motivé de travailler sur quelque chose comme ça.

Je suis également d'accord pour que quelqu'un d'autre prenne le relais et en fasse un package séparé qui dépend du framework principal. Je suis également heureux de le diviser en son propre référentiel sous l'organisation principale si @fluffynuts souhaite le maintenir et le publier. À tout le moins, s'il s'agit d'un package NuGet distinct, nous pouvons suivre les téléchargements et avec cette utilisation.

@jnm2 N'oubliez pas qu'il s'agit d'une source ouverte. Même si nous venons de l'effacer, il existe toujours dans le repo et n'importe qui est libre de le forker et de le libérer lui-même. Nous n'avons pas vraiment à décider si le logiciel va vivre, juste si nous voulons y travailler ou en assumer la responsabilité.

Cela dit, je pense que c'est plus propre si on se lance d'abord dans son propre projet. Ensuite, quelqu'un peut le créer à sa guise OU le maintenir dans le cadre de notre écurie de projets. Je l'avais complètement séparé, mais lors de la révision du code, il a été décidé de ne pas le faire, alors j'ai annulé le changement. Cependant, il est assez facile de le refaire si nous le voulons.

Je pense que c'est mieux si nous prenons des mesures que nous n'aurons pas à revenir plus tard. Ainsi, par exemple, si nous en faisons un assemblage séparé, puis un package séparé et que nous arrêtons plus tard de le maintenir, c'est une sorte d'ordre naturel. Si nous avançons trop vite et devons ensuite le faire reculer, c'est une perte d'efforts.

Alors qu'est-ce qu'on fait avec ça ?

@CharliePoole Je suis d'accord avec tout ce qui "se passe le mieux" avec l'équipe de base NUnit (:

Il semble qu'il y ait une tendance générale à se diviser en un projet séparé avec son propre package - cool.

Ce que j'aimerais réaliser, si possible, c'est que ce projet publie des packages en phase de verrouillage avec le projet principal NUnit (comme mentionné ci-dessus : {nouveau projet} xyz devrait dépendre spécifiquement de NUnit xyz -- pour éviter toute confusion sur les packages bien jouer ensemble et aussi une personne paresseuse comme moi peut juste install-package {new project} et obtenir NUnit avec ça.
Je pense que ce serait une victoire si cela était conservé comme une chose "officielle" de NUnit. Je ne sais pas trop comment vous aimeriez procéder sur ce front. Je suis également toujours prêt à simplement forker et retirer AssertionHelper et à le libérer par moi-même, mais ce n'est pas ma préférence, pour être honnête.
De plus, si un nouveau projet était généré (soit par NUnit Core, soit par moi-même), j'aimerais que le nom soit au moins acceptable pour NUnit Core - je ne veux pas bifurquer et l'appeler quelque chose de simple et évident comme " NUnit.AssertionHelper" ou (mieux, imo) "NUnit.Expectations" (parce que cela décrit ce qu'il fait) et que le NUnit officiel soit sombre à propos de moi en se rapprochant de la marque officielle (:

Fondamentalement, je suis satisfait de tout ce que vous choisissez de faire et je suis toujours prêt à maintenir tout animal qui émerge.

Je pense que ce serait une victoire si cela était conservé comme une chose "officielle" de NUnit. Je ne sais pas trop comment vous aimeriez procéder sur ce front. Je suis également toujours prêt à simplement forker et retirer AssertionHelper et à le libérer par moi-même, mais ce n'est pas ma préférence, pour être honnête.

@CharliePoole Btw c'est ce que je voulais dire par ne pas bloquer. J'aimerais que cela soit libre puisque @fluffynuts est motivé pour y investir.

Je suis heureux de le garder en tant que projet officiel NUnit qui sera maintenu et publié tant que la communauté continuera à l'utiliser et à le maintenir. Il semble également que nous ayons l'accord général de la @nunit/core-team. @CharliePoole voulez-vous rétablir le dépôt précédent que vous avez créé pour cela, ou préférez-vous que quelqu'un d'autre le fasse ?

@jnm2 Pour être clair - au cas où je ne l'

Plusieurs personnes dans la discussion sont membres de l'équipe principale, qui prendra des décisions importantes pour le projet à l'avenir. Cela ne fait que quelques mois qu'ils ont décidé __de ne pas__ accepter ma proposition de séparer AssertionHelper dans son propre dépôt.

Mis à part la contrariété personnelle que je ressens d'avoir abandonné ce travail, je ne pense pas que l'équipe principale fonctionnera bien si ses politiques de base changent tous les mois.

Le fait que quelqu'un dise qu'il aime Assertion helper n'est pas nouveau. Nous avons toujours su qu'il avait ses adeptes.

Le fait que quelqu'un se soit porté volontaire pour y travailler est nouveau mais ne devrait pas, à mon avis, orienter la politique. Un conseil comme la Core Team ne doit pas être réactif mais actif. Si c'était une bonne idée, nous aurions dû travailler à sa mise en œuvre. Cela inclut la recherche active d'un mainteneur.

Je me rends compte que cette affaire de gouvernance est une nouveauté, donc les problèmes sont inévitables. Mais je n'ai détecté aucune prise de conscience qu'il s'agissait d'un renversement complet depuis peu de temps.

Et bien sûr @jnm2 vient tout juste de rejoindre la Core Team.

@fluffynuts Désolé aussi, faites de votre proposition un exemple. Je suis en faveur d'un dépôt séparé et - comme vous l'avez probablement compris - déjà fait le travail pour en créer un il y a quelque temps.

Je pensais que notre plan initial était de ne pas passer à la 3.7 car c'était un changement décisif pour les utilisateurs et nous voulions leur donner le temps de se mettre à jour et nous permettre d'évaluer la réaction. Je pensais que le supprimer sans le déprécier d'abord pour une version ou deux n'était pas une bonne idée.

Je pensais que nous déciderions alors si nous voulions le déplacer vers un nouveau projet et trouver un mainteneur ou le supprimer complètement. Nous avons quelqu'un qui veut le maintenir, donc je suis d' accord pour permettre à

C'était aussi ma compréhension.

@rprouse @ChrisMaddock Je ne veux pas battre un cheval mort ici, mais si c'était votre compréhension, alors nous n'aurions pas dû fusionner un changement qui a marqué AssertionHelper obsolète, avec la notation qu'il allait être supprimé dans une future version . J'ai soumis cela sur la base de ma compréhension de ce que vous disiez. Si nous allons de l'avant avec le dépôt séparé, nous devrions supprimer ObsoleteAttribute.

Avons-nous des divergences d'opinion sur ce que signifie Obsolète ? Question sérieuse. Pour moi, cela signifie que la fonctionnalité est __définitivement__ en train de disparaître. Je pense que c'est aussi comme ça que les utilisateurs le prennent. Je ne l'utiliserais pas pour signifier que nous souhaitons que cela disparaisse ou que cela disparaisse.

@rprouse Rétablir ? AFAIK, il n'y a plus rien à rétablir. Je vais regarder dans GitHub, mais je crois que tout ça a été écrasé. Localement, j'ai supprimé le code car il n'allait pas être nécessaire - nous supprimions la fonctionnalité. C'était un changement que je voulais vraiment voir, mais j'ai été rejeté, à peu près à l'unanimité. Je m'excuse pour ma rancœur à ce sujet, dont je ne savais pas qu'elle était là jusqu'à maintenant.

Si je peux trouver des restes du changement, je les remettrai dans un PR. Sinon, je préfère travailler avec @fluffynuts pour l'aider à le configurer avec une version standard, etc.

Je vais réserver toute autre discussion de « politique » pour l'e-mail ou le dépôt de gouvernance.

Si AssertionHelper passe à un nouveau package NuGet et à un nouvel assembly, c'est en fait une bonne chose que nous l'ayons rendu obsolète à partir de l'assembly du framework NUnit. Nous avons juste besoin de mettre à jour le message d'obsolescence indiquant maintenant aux gens où aller pour le bon assemblage.

@jnm2 Obsolète est pour les choses qui disparaissent complètement. Si la nouvelle classe - où qu'elle se trouve - doit avoir le même nom, alors nous ne devrions pas utiliser Obsolete. L'endroit où vous trouvez la classe fait l'objet d'un autre avertissement, probablement dans la version où le changement se produit.

D'un autre côté, @fluffynuts a suggéré de nouveaux noms pour remplacer AssertionHelper et je suis d'accord qu'un nouveau nom est une bonne idée. Dans ce cas, "AssertionHelper" __is__ va disparaître et Obsolète est sensé. Le message pourrait dire « Use SomeOtherClass, found in some.other.assembly »

Bien sûr, cela n'a d'importance que si nous faisons une version de correctif. Si nous attendons 3.8, il est peut-être déjà parti.

Je rends obsolètes les choses qui se déplacent entre les assemblages car vous avez maintenant accès à deux API identiques disponibles pour IntelliSense en même temps et le message d'obsolescence serait utile, disant de ne pas utiliser AssertionHelpers, NUnit.Framework , utilisez plutôt AssertionHelpers, NUnit.Expectations . Du point de vue de la compatibilité API, changer l'assembly est exactement le même processus de rupture et d'obsolescence que changer le nom. Bien sûr, nous sommes libres d'interpréter les choses comme bon nous semble. Nous n'avons pas à suivre cela. Je reconnaissais juste cela comme une bonne chose que j'ai déjà vue.

@jnm2 Ce n'est possible que si les deux existent en même temps. Je pensais qu'ils ne le feraient pas. Je suppose que nous pourrions laisser un AssertionHelper factice dans le cadre et le marquer comme obsolète. C'est ce que tu penses ?

Dans tous les cas, nous ne pouvons pas le faire pour le moment, car la version séparée d'AssertionHelper n'existe pas encore. En ce moment (3.7.1) c'est ce dont je parlais. Qu'utiliseriez-vous pendant la période où le nouvel assistant d'assertion (ou quel que soit le nom) n'existe pas encore ?

@fluffynuts SI vous allez faire cela, je vous suggère de proposer un plan pour la séquence des choses. Notre version 3.8 ne sera probablement pas avant 3 mois. Nous pouvons avoir une ou plusieurs versions de correctifs - Rob a programmé la 3.7.1 pour quelques jours à partir de maintenant.

Même sans améliorations et en travaillant rapidement, je ne peux pas imaginer que vous serez sur le point de créer une version du nouvel assistant d'assertion avant quelques semaines - peut-être un mois.

Pouvez-vous proposer une séquence d'étapes ?

Qu'utiliseriez-vous pendant la période où le nouvel assistant d'assertion (ou quel que soit le nom) n'existe pas encore ?

Que diriez-vous de garder le message selon lequel AssertionHelpers s'éloigne de NUnit.Framework, ce qui est vrai, ou d'aller au-delà et de dire que nous avons des plans provisoires (ou fermes) pour qu'il soit déplacé vers NUnit.Expectations ?

@CharliePoole bien, une façon de faire les choses (pas nécessairement la _bonne_ façon, mais une façon (: ) serait de bifurquer le référentiel NUnit, sous le compte NUnit, m'accorder un accès de mainteneur/développeur et je clone, en arrachant sans motif tout ce qui n'est pas AssertionHelper ou quelque chose qui le prend directement en charge, ce qui fait que le projet d'hébergement pour AssertionHelper dépend d'un package nuget NUnit.Je pense que cela ne prendrait pas trop de temps.
La partie la plus délicate consiste à m'assurer que ce que j'ai fait est acceptable pour l'équipe NUnit, puis à utiliser votre processus de génération et de publication. Si je devais le pirater rapidement et le publier sur mon compte nuget, cela ne prendrait pas longtemps – mais je ne pense pas que ce soit la bonne voie à suivre, personnellement. J'aimerais que le contrôle de ce nouveau dépôt et des packages qui en découlent existe en dehors de moi-même. Cela ne me dérange pas d'avoir un contrôle conjoint, mais je ne veux certainement pas qu'il apparaisse sur Nuget comme l'un de _mes_ packages, de sorte que si je ne peux plus le maintenir, il ne peut pas simplement être remis à quelqu'un d'autre. Le même raisonnement s'applique au repo.
Ainsi, une séquence possible d'événements pourrait être :

1. Fork NUnit sous le compte NUnit
2. Accordez-moi un accès développeur/mainteneur
3. Je hack et slash pour obtenir le code source à un endroit où ce n'est vraiment qu'un AssertionHelper non modifié avec seulement ce dont il a besoin pour survivre, en fonction d'un package nuget NUnit
4. En attendant, le message Obsolète est mis à jour pour faire référence à l'installation d'un package différent pour obtenir les fonctionnalités requises. Ce message doit inclure le nom final du package -- je suis satisfait de NUnit.Attentes
5. J'espère que je pourrai bientôt sortir une version et qu'il n'y aura qu'un problème mineur pour les utilisateurs finaux. S'il y a "quelques jours", je devrais pouvoir terminer le côté code, en supposant un fork ultra-rapide à vos côtés. Ensuite, c'est à la revue de code de s'assurer que ma version et ma version s'alignent sur la vôtre

Je suis d'accord que Obsolète devrait être pour les fonctionnalités qui vont définitivement mourir, mais c'est (imo) une utilisation acceptable de l'attribut, si pour aucune autre raison que cela il n'y a pas un attribut existant qui offrirait la même fonctionnalité : un avertissement du compilateur avec des instructions sur la façon de le corriger.

Les pensées?

@fluffynuts J'ai localisé une copie de sauvegarde locale du référentiel nunit-assertion-helper. Je peux le renommer nunit-expectations avant de le télécharger si tout le monde aime ce nom. Je dois regarder le code pour voir ce qu'il y a, mais il semble qu'il ait une version correcte, etc. C'est un pur hasard car je ne l'ai pas encore purgé d'une de mes machines.

@nunit/framework-team @nunit/core-team
Sauf avis contraire, je ferai le repo nunit-expectations et l'assembly nunit.expectations.dll. Je vais télécharger ce que je dois maîtriser du nouveau repo - il est inchangé par rapport au framework AFAIK. D'autres modifications peuvent être traitées lors de la révision du code.

@fluffynuts
Il n'y a vraiment pas beaucoup de piratage à faire pour supprimer AssertionHelper. Le PR #1250 l'a complètement isolé dans un seul fichier - avec des tests dans un autre fichier. Il n'est fait référence à aucune autre partie de NUnit. Le nouveau dépôt est ce que nous avons décidé de ne pas faire il y a quelques mois, mais j'ai conservé tous les changements qui isolaient la fonctionnalité.

Nous avons ici deux possibilités :

1. La version 3.7.1 du correctif sortira avant qu'elle ne soit prête.
2. Celui-ci sera prêt à être publié en même temps que le correctif.

Je ne pense pas que nous devrions supprimer AssertionHelper dans le correctif dans les deux cas. Ce n'est pas à ça que sert un correctif. Mais nous devrions probablement changer le message sur l'ObsoleteAttribute et ce sera différent selon que la situation est 1 ou 2. Je pense que nous pouvons supposer 2 si vous voulez faire une version avec seulement les changements de nom. Si vous souhaitez ajouter des fonctionnalités, alors c'est 1. Cependant, gardez à l'esprit que vous pouvez faire des versions aussi souvent que vous le souhaitez. Le seul problème est que ce sera plus facile pour tout le monde dans ce cas si les numéros de version correspondent à ceux du framework que vous référencez.

Victoire épique de

Je pense que la première version du package devrait littéralement consister à le séparer de NUnit, c'est-à-dire à ne rien changer d'autre que le nom de l'assembly et où réside le code (:

Je préférerais, comme mentionné précédemment, faire des versions de package en phase de verrouillage avec NUnit principal, correspondant aux numéros de version - ce sera plus simple à gérer pour les utilisateurs en aval. C'est pour cette raison que je réédite tous mes propres packages PeanutButter.* chaque fois que je mets à jour l'un d'entre eux : des utilisateurs m'ont demandé il y a longtemps quelles versions fonctionneraient les unes avec les autres et c'est beaucoup plus simple de faire correspondre les numéros de version.

Pour les versions de fonctionnalités intermédiaires, -rc[X] pourrait être utilisé dans la version (en utilisant essentiellement le mécanisme de pré-version - en particulier, si je travaille sur quelque chose de nouveau, je voudrais installer le dernier cri dans mon propres projets : rien ne teste mieux une idée que de manger sa propre nourriture pour chien.

Cela me semble bien.

À moins que les noms d'espaces de noms/de classes ne changent, il ne serait pas possible d'utiliser le nouveau package AssertionHelper, alors que l'ancien AssertionHelper existe toujours dans le framework, n'est-ce pas ?

Cela me suggère que 3.7.1 modifie simplement le message obsolète pour mentionner le nouveau package, et que 3.8 supprime l'ancien assistant d'assertion et constitue la première version du nouveau package.

@CharliePoole - Je me demande si nos différentes idées d'"obsolète" sont à l'origine de la confusion. Quoi qu'il en soit, content que vous ayez réussi à récupérer le travail.

Dans le nouveau référentiel, je l'ai mis dans l'espace de noms NUnit.Framework.Extensions. Si tout le monde est d'accord, alors n'importe quel utilisateur peut passer à la nouvelle version à tout moment en utilisant un alias.

J'ai créé le repo et je travaille sur la modification des noms des assemblys et des projets. Ajoutera la référence du package à 3.7, puis demandera un examen. @fluffynuts peut continuer à partir de là.

@CharliePoole Qui est le responsable actuel de ce problème ?

Personne. Je prenais le parti que les problèmes sont locaux aux dépôts, celui-ci concernant la suppression de l'assistant d'assertion étant un problème de framework. J'ai créé le nouveau repo, nunit-expectations. Si c'est voulu, je peux faire un peu plus de travail dessus et nous pouvons y déposer quelques problèmes.

Le côté pratique de ceci est que vous ne pouvez pas vraiment faire un test d'intégration avec le nouveau composant tant que le framework n'est pas modifié et vous ne pouvez pas changer le framework tant que le nouveau composant n'est pas prêt. ??

Ma recommandation était que cela soit dans la version 3.8.

Je devrais ajouter... Je suppose que ce sera un projet contribué, ce qui signifie normalement que quelqu'un entre en tant que chef de projet plutôt que l'un de nos committers. Cependant, si l'un de nos nouveaux membres de l'équipe (que moi ou Rob) voulait prendre cela comme premier plan en tant que chef de projet, je pense que ce serait une bonne expérience, menant peut-être à de plus grandes choses. 😺 🥇 😈

@CharliePoole Je me demande simplement quel travail reste à faire pour empêcher _ce_ problème d'être fermé et si nous savons qui le fera.

@jnm2 Ce problème concerne la suppression des fichiers du framework et la documentation de la manière dont les utilisateurs doivent gérer le changement. C'est trivial, mais quelqu'un doit décider quand le faire. Nous ne voulons probablement pas qu'il soit disponible, car cela nécessite une coordination avec l'autre projet qui remplace la fonctionnalité.

Je devrais probablement faire construire l'autre projet afin que quelqu'un puisse le prendre en charge en conjonction avec ce problème.

@rprouse Voudriez-vous que cela soit fait juste avant la sortie de la 3.8 ou à tout moment pendant la période OK ?

Waouh, 60 commentaires. Je pense qu'on passe plus de temps à parler de choses qu'à coder 😈

Si @fluffynuts veut prendre en charge la maintenance, que diriez-vous de lui donner la possibilité de bifurquer et de préparer une pull request. Je vais créer un dépôt dans lequel il pourra travailler et nous pourrons voir comment cela se passe, il suffit de dire le mot.

Quant à la suppression d'AssertionHelper de ce projet, nous l'avons simplement déprécié dans la version 3.7. Et si nous attendions une version pour donner aux gens le temps de mettre à jour leur code ? Cela donnera également à @fluffynuts une chance de sortir quelque chose. S'il évolue rapidement, nous pouvons toujours réévaluer pour la version 3.8 car les utilisateurs auront quelque chose vers quoi passer.

@rprouse Je suis d'accord pour parler.

Peut-être qu'il y a tellement de commentaires que l'essentiel s'en perd. Pourquoi avons-nous besoin d'une fourchette? Nous avons déjà fait tout le travail et l'avons fusionné... sans laisser tomber deux fichiers. Le dépôt séparé existe déjà.

Je pense qu'il attend en fait que vous disiez __quand__ vous voulez que cela se produise, il n'y a pratiquement plus de travail à faire et le risque est que cela se fasse trop tôt et stagne ensuite si vous n'êtes pas prêt à le fusionner.

J'ai supposé que vous voudriez qu'il soit supprimé dans la 3.8 et je vous demandais si vous vouliez attendre pour le faire dans la branche de publication ou voudriez-vous qu'il le fasse maintenant, afin qu'il disparaisse pour tous ceux qui utilisent des versions de développement.

@CharliePoole J'ai clairement raté quelque chose pendant que je rattrapais mon retard. Je pensais que vous aviez perdu votre travail sur le repo séparé. Où est-il maintenant ? Je ne le vois pas sous l'organisation nunit ou votre compte. Si ce référentiel existe et que nous pouvons aider @fluffynuts à créer une version, alors je pense que nous pouvons procéder à la suppression d'AssertionHelper de ce référentiel et créer la version distincte d'AssertionHelper juste avant la version 3.8.

Si nous n'avons pas de version séparée d'AssertionHelper disponible, je préférerais attendre une autre version pour donner aux gens plus de temps pour mettre à jour.

Je ne pense tout simplement pas que nous devrions faire le travail de maintenance d'AssertionHelper. Si la communauté le veut et s'intensifie, alors cela nous permet de le retirer du framework plus tôt car il y aura une alternative facile. Si la communauté ne s'intensifie pas, alors nous donnons aux gens un peu de temps et c'est parti en 3.9.

Voir https://github.com/nuni/nunit/issues/1212#issuecomment -311964899

Résumé : j'ai trouvé une sauvegarde du référentiel local que j'ai créé et je l'ai téléchargée sur https://github.com/nuni/nuni-expectations. Nous avons fusionné le PR #1250 en février dernier, ce qui a éliminé toute notre propre utilisation d'AssertionHelper et l'a isolé en deux fichiers.

Je pense que je devrais jeter un œil pour me rafraîchir la mémoire et créer au besoin sur les attentes de nunit... c'est-à-dire est-ce qu'il se construit, etc.

salut tout le monde

Cela fait un moment que c'est ouvert. Je sais que j'ai proposé de maintenir AssertionHelper, mais j'ai peut-être trouvé un moyen qui rend tout le monde heureux - les personnes qui souhaitent le déplacer ainsi que les personnes (comme moi) qui utilisent actuellement la syntaxe.

J'ai mis en revue mon code rapide d'hier soir: https://github.com/fluffynuts/NUnit.StaticExpect qui est sur nuget.org . Je l'ai utilisé pour remplacer toutes les utilisations d'AssertionHelper dans un projet - bien que mon utilisation ne soit peut-être pas aussi étendue que d'autres, donc j'apprécie les commentaires.

Fondamentalement, c'est juste un wrapper autour des appels Assert.That , mais il a fourni un remplacement instantané pour AssertionHelper, au moins, pour moi. Et cela atteint mon objectif de ne pas exiger que tous les appareils de test héritent d'une autre classe.

Cela me fournit également un palliatif alors que je termine une première version de proche de Chai (par exemple Expect(value).To.Equal(otherValue) ) avec une expérience de type Jasmine pour l'extension grand public. Il s'harmonise avec NUnit, sans en dépendre directement, en lançant des AssertionExceptions si le type est trouvé au moment de l'exécution, sinon en lançant ses propres exceptions.

Jusqu'à présent, tout prend forme, mais je souhaite inclure quelques fonctionnalités supplémentaires avant une version 1.0. Si des utilisateurs de Expect sont intéressés, regardez peut-être ce projet ou faites-le moi savoir afin que je puisse vous tenir au courant.

@fluffynuts Cela ressemble à une bonne alternative. Savez-vous si d'autres IDE et compilateurs prennent en charge la syntaxe ?

En ce qui concerne notre propre support NUnit, ce que je vois se produire, c'est que je vais m'assurer que le nouveau projet est en cours de construction après mes vacances, puis laisser le calendrier de basculement à @rprouse et à l'équipe du framework.

@CharliePoole using static fait partie de la spécification C#6 https://msdn.microsoft.com/en-us/magazine/dn802602.aspx donc il _devrait_ être pris en charge par tout ce qui prend en charge la syntaxe C#6 ( :

Bien qu'il puisse y avoir des compilateurs que je ne connais pas et qui ne prennent pas en charge cela, certainement n'importe quel Visual Studio moderne le prendra en charge immédiatement. Les anciennes versions de Visual Studio (et je suppose que d'autres processus utilisant msbuild) peuvent obtenir une prise en charge via le package nuget Microsoft.Net.Compilers (et ensuite elles bénéficient également de la prise en charge de C#7 - ce qui est également une bonne chose (: ).
Mono prend en charge C#6 : http://www.mono-project.com/docs/about-mono/languages/csharp/ et je fais l'hypothèse audacieuse que dotnet core, étant le nouveau venu sur le bloc, prend en charge un spécifications de 2014 ( :

Donc, même si je pense que cela devrait être une alternative viable pour tout le monde, je suis également assez ouvert à ce qu'on me dise que je me trompe ( :

Il est donc au moins possible pour l'équipe du framework de supprimer complètement cette fonctionnalité, à condition que cela ne les dérange pas de perdre la rétrocompatibilité pour ce qui est probablement un petit nombre d'utilisateurs.

Personnellement, je continuerais à maintenir le projet séparé, mais je ne l'améliorerais pas à l'avenir.

Je suis d'accord - bien que cela ne m'affecte pas, NUnit a une très large portée et je suis sûr qu'il y a quelqu'un que cela aurait un impact.

Après discussion avec @BobSammers , qui a apporté une contribution précieuse à NUnit.StaticExpect, je voudrais juste rappeler à toute personne abonnée ou tombant sur ce fil que NUnit.StaticExpect (nuget: https://nuget.org/packages/NUnit .StaticExpect ) fournit un remplacement simple pour AssertionHelper. La page GitHub est également un bon endroit pour soulever des problèmes et discuter, si nécessaire.

Je ne voulais pas être un troll sur ce forum, mais @BobSammers a souligné que les gens ne se rendaient peut-être pas compte de l'exhaustivité de la solution et de la facilité de basculement, alors je le répète. Sous le capot, il effectue toujours des appels NUnit "corrects" (en effet, de nombreuses fonctionnalités sont littéralement implémentées en tant que propriétés de transmission), donc cela ne fait que fournir le sucre syntaxique auquel les utilisateurs d'AssertionHelper ont été habitués tout en leur permettant de se préparer au suppression éventuelle de la classe.

C'est bien de voir NUnit.StaticAttendez l'attention @fluffynuts - c'est une excellente solution au problème !

@nunit/framework-team - Je pense que nous sommes probablement sur le point de pouvoir clore ce problème. Puis-je proposer ce qui suit, en fonction de notre situation actuelle ?

1. AssertionHelper reste obsolète et non maintenu pour le reste de la série 3.x.
2. AssertionHelper est supprimé dans 4.0
3. Nous mettons à jour la documentation et l'ObsoleteAttribute pour recommander NUnit.StaticExpect comme remplacement immédiat.
   ~4. NUnit.StaticExpect continue de fonctionner comme une bibliothèque tierce, qui fournit désormais une syntaxe _alternative_, par opposition à une syntaxe « héritée ». Nous avons déjà parlé de le faire au sein de l'organisation NUnit - je ne vois plus aucune raison d'intégrer cela dans l'organisation. @fluffynuts - si vous n'êtes pas du tout d'accord, je n'aurais personnellement aucune objection à déplacer cela dans l'organisation - mais je pense que ce qui est essentiel, c'est que vous restiez le responsable en tant que projet indépendant. 🙂~ ( A discuter dans la gouvernance )

Toutes les pensées sont les bienvenues - @rprouse devrait probablement passer le dernier appel ici, compte tenu des implications.

@ChrisMaddock Je n'ai aucun problème à intégrer cela dans l'organisation NUnit - en effet, je pense que cela pourrait être une bonne idée car cela ressemblera à une alternative plus "officielle" au lieu d'un code créé par un arbitraire code-monkey sur les interwebs (: Je ne sais pas comment cela est réalisé, donc je me réjouis des informations (:

J'ai également l' intention de rester en tant que mainteneur - mais ce pourrait être une bonne idée, s'il y a suffisamment d'intérêt pour le projet, de fournir un accès complet à quelqu'un d'autre (peut-être @BobSammers , qui a déjà contribué), pour ceux typiques "

La même chose devrait être faite pour la gestion des paquets sur nuget.org, pour les mêmes raisons.

@fluffynuts D'accord ! ??

Discutons de l'avenir de NUnit.StaticExpect séparément, en matière de

En gardant le sujet de ce problème, comment l'existence de NUnit.StaticExpect impacte-t-elle notre décision concernant AssertionHelper ? Je n'en avais pas entendu parler avant et cela semble être une excellente solution. J'étais prêt à laisser tomber AssertionHelper froid - même sans remplacement - et je le suis toujours. Qu'en est-il des autres membres de @nunit/framework-team ? Est-ce que NUnit.StaticExpect comme alternative vous amène à être prêt à le laisser tomber ?

Pour une question mineure, je n'appellerais pas cela un remplacement "drop-in" puisque l'utilisateur doit changer le code. C'est un petit changement, mais toujours un changement. Je soupçonne que cela ne remplacera peut-être que les utilisateurs de C#. En tout cas, j'espère que c'est un remplacement suffisant pour nous faire accélérer la chute de AssertionHelper .

NUnit.StaticExpect comme alternative vous amène-t-il à être prêt à le laisser tomber ?

Si nos notes de version, et ce que les gens verront visiblement dans le gestionnaire de packages NuGet, affichent un avertissement en haut de la description comme : « Avertissement : l'AssertionHelper obsolète a été supprimé. Pour continuer à l'utiliser, vous devez également référencer le NUnit. Forfait StaticExpect." – alors personnellement, je suis tout aussi heureux de le faire à la prochaine version mineure ou de continuer à attendre.

@jnm2 L'avis devrait ressembler davantage à "référencer le package NUnit.StaticExpect" et

• arrêter d'hériter d'AssertionHelper
• ajouter une instruction using
• éventuellement quelques corrections de code ( @fluffynuts y a-t-il autre chose ?)

Je le laisserais tomber moi-même. L'utilisation par IMO StaticExpect de méthodes statiques au lieu de l'héritage est une amélioration significative.

@CharliePoole Je ne vois rien à ajouter, à première vue, bien que la plupart de ce que vous mentionnez devrait déjà être dans le README.md (et s'il y a quelque chose qui ne l'est pas, il devrait être ajouté ; en effet, ce README devrait , imo , fournissez toutes les informations dont une personne a besoin pour changer, car ce serait idiot et ennuyeux si ce n'était pas le cas !).

Donc, si vous avez le temps, j'apprécierais une critique et un commentaire sur https://github.com/fluffynuts/NUnit.StaticExpect/blob/master/README.md tel qu'il intègre, d'une manière facile à suivre , les étapes requises pour passer de AssertionHelper à NUnit.StaticExpect. Si ce fichier README.md devient suffisamment clair et définitif, il peut être suffisant de faire en sorte que l'avis de dépréciation ressemble à "AssertionHelper a été déprécié en faveur de NUnit.StaticExpect. Lisez https://github.com/fluffynuts/NUnit.StaticExpect/ blob/master/README.md pour en savoir plus".
Les pensées?

@fluffynuts La seule chose que je voudrais voir ajoutée serait quelques exemples supplémentaires, par exemple :

• Utilisation de contraintes (en remplacement Has syntaxe Is et Has )
• Utiliser avec autre chose qu'Assert/Expect : par ex. Assume, Warn.

Je voulais juste être sûr que c'est un remplacement complet (ou donner un avis si ce n'est pas le cas)

Quel est le problème avec le code non-C# ? Pouvez-vous l'utiliser en VB par exemple ?

@fluffynuts Pour être clair, je AssertionHelper sans remplacement mais j'ai été en minorité. Cependant, si nous recommandons un remplacement, j'aimerais qu'il soit parfaitement clair ce qu'il remplace et ce qu'il ne remplace pas (le cas échéant). J'aime l'idée que votre readme devrait tout expliquer.

@CharliePoole Je suis totalement d'

• Je vais certainement ajouter d'autres exemples
• Assume / Warn ne semble pas faire partie de la syntaxe AssertionHelper , ils ne sont donc actuellement pas implémentés dans NUnit.StaticExpect . Actuellement, nous avons deux méthodes de test pour prouver la parité : les tests basés sur la réflexion qui montrent que (dans tous les cas sauf 2) que les méthodes et propriétés qui seraient trouvées sur AssertionHelper sont imitées via des méthodes et propriétés statiques sur Expectations (les deux mentionnés ayant des tests comportementaux dans des cas particuliers car ils ont divergé de la signature exacte offerte par Assert.That ) ainsi que le montage de test complet de AssertionHelper exécuté contre Expecations au lieu d'hériter de AssertionHelper . L'objectif principal du projet est de fournir un remplacement minimal pour AssertionHelper , c'est donc à peu près l'état actuel. Bien entendu, Assume et Warn sont toujours disponibles pour l'utilisateur via des appels réguliers.
• code non-C# : c'est une bonne question. C'est tout .net, donc, bien sûr, vous pouvez l'utiliser à partir de, disons, VB; mais je pense que votre question concerne davantage les importations statiques dans VB.NET - une question à laquelle je ne peux pas répondre pour le moment (et à laquelle mon google-fu n'a pas répondu jusqu'à présent), mais à laquelle je trouverai une réponse définitive en créer simplement un projet et essayer. Je devrais être en mesure de faire rapport ici plus tard aujourd'hui à ce sujet.

Et pour réitérer, pour plus de clarté : j'apprécie les critiques, les commentaires et les suggestions sur le README, car il devrait vraiment être un point d'atterrissage convivial et informatif pour tous ceux qui envisagent de passer à NUnit.StaticExpect . Toutes les suggestions sont les bienvenues.

@CharliePoole à ma grande joie :
Imports NUnit.StaticExpect.Expectations
fournit la même fonctionnalité dans VB.NET que
using static NUnit.StaticExpectations.Expectations
fait en C#. Je viens de tester cela maintenant dans une petite bibliothèque de test VB.NET.

(et, en remarque, je comprends maintenant pourquoi AssertionHelper copié les méthodes sur (par exemple), Is - parce que je ne peux pas, dans VB.Net, faire
Expect(1, Is.EqualTo(1)) ,
mais je peux (via l'import statique) faire :
Expect(1, EqualTo(1))

J'ai donc juste besoin d'étoffer davantage le README. Je peux y jeter un œil ce soir (:

Je pensais seulement que vous voudriez peut-être faire savoir aux gens qu'ils peuvent utiliser Assume ou Warn avec les propriétés de construction de contraintes statiques.

WRT Is en VB - c'est pourquoi nous avons Iz . ??

Comme @fluffynuts l'a mentionné, StaticExpect teste la fonctionnalité AH par réflexion pour assurer une couverture complète de AH . Actuellement, 2 de ces tests échouent (en fait sont des cas particuliers) car la fonctionnalité de AH a divergé des membres Is et Does qu'il masque (en particulier InRange et Exactly , respectivement).

Je serais intéressé de savoir combien de temps AH est susceptible de rester dans NUnit. S'il est probable que ce soit pour quelques versions supplémentaires (ce qui est logique si des panneaux vers StaticExpect peuvent être ajoutés à son message d'obsolescence), seriez-vous intéressé par une demande d'extraction de modifications de AssertionHelper.InRange() et AssertionHelper.Exactly() pour fermer la divergence (je suppose que AH été oublié accidentellement) ? Cela donnerait AH et SE exactement équivalents en fonctionnalités avant que AH soit obsolète (et aider avec la suite de tests SE !).

@BobSammers Nous n'avons pas ajouté de fonctionnalités à AssertionHelper depuis un certain temps, donc cela ne me surprend pas qu'il ait pris du retard sur certaines nouvelles fonctionnalités. N'hésitez pas à créer un problème pour toute divergence que vous souhaitez corriger... Je l'ai dit ainsi, car cela n'aurait probablement pas beaucoup de priorité autrement.

@nunit/framework-team Il n'y a pas eu beaucoup de commentaires récents ici, il est donc difficile de répondre à @fluffynuts et @BobSammers de manière significative. Il semble que nous ayons "en quelque sorte" décidé de nous débarrasser de AssertionHelper dans le passé et je pense que nous avions prévu de diriger les utilisateurs vers l'assemblage séparé que j'ai créé. Mais nous souffrons un peu de l'absence d'une décision claire, semble-t-il.

Je pense que nous avons discuté jusqu'à présent de deux directions fondamentalement différentes :

1. Arrêtez complètement la prise en charge de AssertionHelper .
2. Déplacez-le dans un package distinct, que nous pourrons ultérieurement déprécier et supprimer.

Toutes les autres options dont nous avons discuté me semblent n'être que des détails dans un cas ou dans l'autre. La plupart d'entre eux ont à voir avec la rapidité avec laquelle nous mettons en œuvre une stratégie ou l'autre.

La disponibilité de StaticExpect semble rendre l'alternative (2) un peu ridicule. Il n'y a aucune raison pour nous de concurrencer StaticExpect , d'autant plus que cela semble être une meilleure solution que l'héritage. Je suppose que cela pourrait ouvrir une troisième option, si nous voulons continuer à supporter l'API

1. Incorporez StaticExpect dans NUnit, en remplaçant AssertionHelper . En fait, NUnit avait une classe statique nommée ConstraintFactory jusqu'à tout récemment, qui aurait pu être utilisée de la même manière que StaticExpect si l'un d'entre nous y avait pensé. ??

@rprouse Cela me semble être l'une de ces décisions stratégiques qui doivent être prises d'une manière ou d'une autre par le chef de projet. Après cela, nous pourrons débattre des détails.

Quelle que soit la manière dont les choses se passent, j'ai mis à jour le fichier README.md ce soir, en empruntant en grande partie à la documentation AssertionHelper.
En remarque, j'ai également mis à jour la solution pour utiliser un seul projet multi-cibles, donc c'est un peu plus soigné. Et inclus la documentation XML générée dans le package.

@nunit/framework-team Il n'y a pas eu beaucoup de commentaires récents ici, il est donc difficile de répondre à @fluffynuts et @BobSammers de manière significative.

Désolé Charlie - mais ça ne fait qu'un peu plus de 24 heures ! J'ai peur de ne pas pouvoir toujours répondre aux choses aussi vite. ??

Auparavant, je souhaitais simplement supprimer AssertionHelper dans une version mineure. Ce qui m'a fait changer d'avis, ce sont les problèmes que nous avons rencontrés avec la suppression de TestFixtureSetUpAttribute, etc. dans la version 3.8. Pour résumer - dans la version 3.8, nous avons supprimé certains attributs qui étaient obsolètes depuis la version 3.0 - en supposant qu'il s'agirait d'un correctif de recherche/remplacement trivial pour tous les utilisateurs qui en dépendent encore. Ce que nous avons découvert, c'est que certaines bibliothèques tierces s'appuyaient toujours sur ces attributs, ce qui signifie que les utilisateurs de ces bibliothèques tierces ne pouvaient pas mettre à jour NUnit jusqu'à ce que la bibliothèque soit corrigée. Bien sûr - ce n'est pas impossible, mais cela signifiait que ce que nous supposions être une solution triviale, n'était pas du tout pour un certain nombre d'utilisateurs. La même situation pourrait bien s'appliquer ici.

AssertionHelper est maintenant entièrement séparé du reste de la base de code grâce au travail de

En ce qui concerne les points que vous avez exposés Charlie, je suis d'accord (2) serait maintenant idiot. Sur (3) - Personnellement, je souhaite affiner l'API de base que nous fournissons et je pense que NUnit.StaticExpect serait une excellente syntaxe alternative tierce, plutôt que quelque chose qui devrait faire partie de la bibliothèque principale. Ma préférence globale serait toujours comme je l'ai proposé ci - dessus !

Je vais également lancer cette question de contribution au projet dans la gouvernance ce soir - désolé, j'ai manqué de temps hier.

Question distincte pour discuter de l'intégration de NUnit.StaticExpect dans l'organisation NUnit : https://github.com/nuni/governance/issues/33

@ChrisMaddock En fait, c'est vous qui avez déjà répondu ! Cela dit, nous semblons avoir laissé cela indécis pendant environ neuf mois et nous sommes restés silencieux depuis juillet, jusqu'à ce que

J'aime votre proposition avec une réservation. Je pense que nous devrions modifier le message Obsolete pour recommander l'utilisation de StaticExpect maintenant, plutôt que d'attendre.

FWIW, mon désir de supprimer cela plus tôt était fondé sur l'idée que je devais faire partie de l'équipe afin d'ajouter mon projet de remplacement. Je voulais juste sortir un projet en attente de mon assiette. Si nous pouvons déposer un package AssertionHelper séparé en option, je suis heureux que la fonctionnalité traîne jusqu'à la version 4.0.

J'aime votre proposition avec une réservation. Je pense que nous devrions modifier le message Obsolete pour recommander l'utilisation de StaticExpect maintenant, plutôt que d'attendre.

Je suis d'accord - il s'agissait de trois points distincts - et non d'une liste ordonnée. ??

Je pense que https://github.com/nuni/nuni/issues/1212#issuecomment -337695330 capture très précisément mes pensées (et s'exprime bien mieux que je ne peux le faire), en particulier en ce qui concerne "l'éclaircissement de l'API de base".