Autofixture: Quelle est la prochaine étape pour AutoFixture ?

@Kralizek , merci d'avoir demandé.

Je ne peux parler que pour moi, c'est en fait (toujours) comme je l'ai écrit dans https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457 :

Ça me va, si j'ai les connaissances requises pour examiner le(s) PR. Habituellement, je passe en revue (avec plaisir) les parties de la base de code sur lesquelles j'ai déjà travaillé, créé ou contribué.

Si j'ai raté une demande d'extraction ou un problème où j'ai été explicitement mentionné, veuillez m'en informer. Cela fait un moment que quelqu'un ne m'a pas ajouté en tant que critique, ou m'a explicitement mentionné sur le(s) problème(s)...

Merci, @moodmosaic , d'avoir pointé vers le #703. Ma position est toujours la même qu'à l'époque : je suis hors du projet AutoFixture, bien que je sois heureux d'aider avec des conseils s'ils sont explicitement invoqués.

Je pense qu'il est logique d'ouvrir ce sujet si rien ne semble se passer. Il se peut que les mainteneurs actuels aient également évolué. Voyons si nous obtenons une réponse de l'un d'entre eux. Si ce n'est pas le cas, veuillez me contacter à nouveau dans, devrions-nous dire, une semaine environ ?

Je peux toujours aider à revoir les relations publiques occasionnelles dans des domaines avec lesquels j'ai eu de l'expérience, mais je suppose que ces domaines sont probablement rares ces jours-ci.

Si les choses ne bougent pas, voyons si nous pouvons comprendre pourquoi, puis voyons si nous pouvons aider à trouver plus de personnes pour aider si nécessaire.

Je n'ai pas l'intention de reprendre le contrôle du projet, mais pour autant que je sache, j'ai toujours un accès en écriture au référentiel. Si quelqu'un d'autre se porte volontaire pour diriger le projet, je serai heureux de contribuer à sa réalisation.

Salut les gars!

Il y a aussi mes commentaires qui manquent ici. Pas officiellement, mais on s'attend probablement à ce que je sois le responsable le plus actif du projet pour le moment.

Au départ, j'étais très passionné par la maintenance et j'avais peu d'idées sur ce qui pourrait encore être amélioré. Même aujourd'hui, je vois des choses qu'il est logique de faire, du moins du point de vue de la maintenance (par exemple, supprimer la prise en charge de .NET Standard 1.x).

Récemment, j'ai cessé de soutenir le projet et j'ai moi-même identifié quelques raisons à cela.

AVIS DE NON- RESPONSABILITÉ : Le but n'est pas de blâmer qui que ce soit, alors ne le prenez pas personnellement. Je veux plutôt partager ma propre expérience afin que nous puissions voir s'il y a quelque chose que nous pouvons faire à ce sujet et si cela en vaut la peine.

Difficile de changer de projet.

C'est très difficile de changer ce projet, car j'ai le sentiment fort que tout le monde essaie de préserver l'héritage laissé par Mark. Il n'y a aucune liberté d'essayer quoi que ce soit d'autre, sauf ce que Mark ferait. Mark a été cité dans presque tous les PR où il n'a pas participé en personne :)

À un moment donné, j'ai commencé à sentir qu'il devenait trop difficile de modifier quoi que ce soit ici. Et ça a tué la passion que j'avais pour le projet.

Même si Mark est parti, je pense toujours personnellement que la propriété du projet lui appartient toujours. Je ressens beaucoup de pression interne/externe lors de la prise de décisions, car il y a une chance de casser violemment et barbare quelque chose qui a été si bien conçu par Mark. Une partie de cette perception a été créée uniquement par moi, mais il y a des parties où d'autres responsables ont contribué à faire une telle impression.

C'est probablement juste la différence avec mes attentes et la réalité. Je pensais que je serais capable d'exprimer et d'essayer mes idées avec ce projet, qu'il sera agile, frais et plein de nouvelles fonctionnalités. Mais en réalité, cela ressemblait à un projet hérité où vous n'êtes pas autorisé à changer beaucoup, car les choses fonctionnent très bien de toute façon.

J'admets que certaines de mes propositions auraient pu ne pas être idéales et, bien sûr, je n'ai pas autant d'expérience que l'honorable Mark. Mais nous aurions pu être plus libres dans les décisions que nous avons prises, donc le projet est plus vivant.

C'est un peu solitaire

Lorsque j'ai rejoint le projet, je m'attendais entre autres à participer à des discussions agiles, à faire partie de l'équipe, à socialiser avec les autres. Malheureusement, par manque de temps et/ou d'autres facteurs, les autres responsables n'ont pas trop participé aux discussions et j'ai finalement commencé à sentir que j'étais seul ici. J'ai l'impression que les autres responsables n'ont pas trop de temps/passion pour ce projet en ce moment, alors j'ai finalement commencé à partager la même chose.

Je ne travaille pas activement avec AutoFixture pour le moment

Pour le moment, je n'écris pas beaucoup de code back-end, alors n'utilisez pas trop AutoFixture. Je suis toujours un grand plaisir du projet et je crois que cette bibliothèque est un must have. Mais parce que je n'écris pas trop de tests, je n'exige personnellement aucun changement.

Pour aller plus loin cela ne me dérange pas de participer à la vie du projet et de partager mes connaissances le cas échéant. S'il y a un besoin, je pourrais aussi aider avec le code/la maintenance. Mais en ce moment, malheureusement, je n'ai pas assez de passion et d'énergie pour être un chef de file. Si nous avons un candidat pour cela en qui nous avons confiance et qui est plein de passion, nous devrions certainement l'inviter et en faire l'un des mainteneurs.

Tout d'abord, je tiens à m'excuser auprès de l'équipe @AutoFixture/core pour ne pas vous avoir répondu dans la discussion #703. Oui, c'était une période chargée pour moi (et c'est toujours le cas) mais je n'étais pas si occupé que je ne pouvais pas répondre. Je n'ai tout simplement reçu aucune notification pour aucune de mes mentions et je n'ai pas pensé à revenir sur la discussion. Je viens littéralement de le découvrir maintenant que j'ai revisité # 703. Encore une fois, je suis désolé. 😞

Ma position sur l'avenir d'AutoFixture est la même que celle que j'ai exprimée en 2016 . Je pense que AutoFixture est assez stable et ce depuis des années maintenant. Si quelqu'un veut le prendre dans une direction différente, je pense qu'il ferait mieux de partir d'une table rase. Le concept de génération automatique de données de test est très bon et AutoFixture n'est sûrement pas la _seule_ façon de le faire sur la plate-forme .NET.

Cela ne veut pas dire qu'AutoFixture est exempt de bogues. Ce que je dis, c'est que le volume et l'étendue de la maintenance sont suffisamment petits pour qu'ils puissent rester sous la responsabilité de l'équipe @AutoFixture/core.

Avons-nous besoin d'un développeur principal ? L' histoire de l'open source semble suggérer qu'un projet sans responsable individuel finira par être abandonné. Mais qu'en est-il d'un groupe de prospects ?

Je dis que nous essayons d'aller de l'avant avec le modèle actuel moins un responsable désigné et de voir comment cela se passe.

AutoFixture est un si bon projet qu'il sera très triste de le voir disparaître lentement.

Étant donné que @zvirja est le mainteneur le plus actif/principal du projet. Je pense qu'il est logique pour lui de diriger l'évolution de ce projet. Maintenir un projet open source demande beaucoup d'efforts et de temps. Personnellement, cela ne me dérange pas de faire un don pour faire avancer ce projet. Et merci @zvirja

Quelqu'un devrait signaler l'éléphant dans la pièce, alors autant être moi.

Ce fil ressemble beaucoup à des funérailles (ou à une perspective de regret)

Je crois que nous (la communauté) devrions nous concentrer davantage sur la recherche d'un moyen de sortir de la situation dans laquelle nous nous sommes retrouvés plutôt que de nous excuser.
Jusqu'à présent, ce fil a été très bon pour signaler les problèmes (n'hésitez pas à compléter):

1. Les mainteneurs actuels n'ont pas le temps/ne sont pas intéressés par le projet
2. Le projet est difficile à maintenir
3. La revue de code est trop restrictive

Pouvons-nous maintenant établir une liste d'actions que nous pouvons entreprendre ?

Si quelqu'un s'en soucie, voici mon point de vue :

1. Acceptez de nouveaux membres dans la communauté. @Kralizek existe depuis un moment, il pourrait être un bon candidat. Peut-être avez-vous une autre équipe aux côtés de @AutoFixture/core ?
2. Créer un arriéré de problèmes, hiérarchiser, demander de l'aide à la communauté
3. Assouplir la revue de code. On ne peut pas s'approprier un projet s'il est constamment giflé par l'ancien propriétaire.
   Autoriser les expériences, peut-être créer un package supplémentaire AutoFixture.Experimental , pour les choses, qui n'est pas encore confirmé pour accéder à la version principale de la bibliothèque (comme Boost pour la bibliothèque C++ standard).

Je suis d'accord avec @zvirja , le projet est très intimidant. J'ai découvert AutoFixture il y a environ deux ans et ce n'est que récemment que j'ai eu le courage de soumettre un PR.
Je crois qu'il y en a d'autres qui ressentent la même chose. Les personnes qui utilisent l'outil et aimeraient le voir prospérer.

Merci @aivascu d'avoir pointé l'éléphant dans la pièce.

Je suis d'accord avec votre analyse mais j'aurais aussi une quatrième option (même si je la détesterais) : un nouveau fork pour donner à ses mainteneurs la liberté de se déplacer et de déconner.

Aussi, merci d'avoir mis mon nom dans la liste mais malheureusement je n'ai pas tellement d'expérience avec les internes de la bibliothèque et je ne peux vraiment pas m'y déplacer.

Je peux intervenir avec plaisir quand il s'agit de l'expérience utilisateur...

Que diriez-vous d'un programme de parrainage/soutien pour attiser l'enthousiasme pour le maintien du projet ?
C'est un repo populaire après tout.

Mes deux centimes d'utilisation d'AutoFixture au cours des trois dernières années :

Je pense que le nom de marque pour AutoFixture est génial. C'est un nom sympa.

Il est populaire sur Stack Overflow. [autofixture] a 506 questions, tandis que [xunit.net] en a 801. Pour qu'il soit presque aussi populaire que le framework de test quasi-officiel de .NET Core est plutôt remarquable, et en partie grâce au dévouement incessant de Mark à enseigner (et à être un excellent professeur). Et le blog de Mark est comme une source de connaissances sur les tests gratuits.

Je pense que l'API d'AutoFixture est plutôt difficile à apprendre.

Parties d'AutoFixture que j'aime :

• Capacité à utiliser le modèle de conception de conteneur Auto-Mocking (probablement le concept de test le plus puissant auquel j'ai été présenté en tant qu'ingénieur).
• Fixture.Freeze est incroyable
• Extension AutoMoq pour permettre de créer rapidement des luminaires pour les choses qui nécessitent une simulation
• Possibilité de générer automatiquement un graphique d'objet d'entité et de tester mon modèle de référentiel générique et de garantir une couverture de code de test d'intégration de bout en bout pour mes référentiels Entity Framework.

Parties d'AutoFixture que je n'utilise jamais directement :

• Fixture.Inject

Parties d'AutoFixture que je souhaite améliorer/étendre

• Voir mon numéro créé hier : #1179
• Possibilité d'échanger le comportement par défaut des Guids contre des chaînes avec quelque chose de plus agréable, comme Waffle Text Generator. Je me rends compte que vous pouvez le faire aujourd'hui, mais si # 1179 était travaillé, nous pourrions brancher des sélecteurs d'éléments arbitraires avec un fournisseur de données personnalisé.
• AutoFixture est lent et n'utilise aucune astuce moderne pour accélérer la compilation des expressions, comme le fait le projet DryIoC de Maksim Volkau avec FastExpressionCompiler de Maksim https://github.com/dadhi/FastExpressionCompiler

Parties d'AutoFixture que je n'aime pas (principalement mineures):

• Luminaire.Personnaliserfonctionne toujours de manière incorrecte avec Visual Studio Intellisense.
• Écriture de personnalisations et pourquoi la méthode Customize ne vous permet pas d'injecter une personnalisation. Ce genre de choses est baroque et ennuyeux et crée une énorme courbe d'apprentissage.
• Les personnalisations et les constructeurs de spécimens et les choses sont partout. C'est désorganisé.
• Vocabulaire étrange pour certaines choses
• Il est assez difficile de s'habituer à l'ensemble du modèle de conception Do..Without . Cela fonctionne, mais c'est verbeux et ne vous aide pas avec les entités récursives. Pour cela, vous avez besoin de comportements spéciaux pour indiquer à AutoFixture de créer une table de hachage d'objets déjà créés.
• Pas de syntaxe simplifiée pour les tâches courantes
• Conception monolithique qui nécessite une compréhension approfondie des composants internes uniquement pour résoudre les problèmes. Vous ne pouvez pas simplement utiliser des morceaux. Vous devez à peu près regarder le cours PluralSight de Mark juste pour dépasser la courbe d'apprentissage initiale, ou travailler avec un développeur expert en AutoFixture, afin de comprendre pourquoi AutoFixture est si génial.
• La position de Mark selon laquelle AutoFixture ne devrait générer que des "valeurs anonymes". Cela crée beaucoup d'écriture de code tiers pour faire avancer les choses. Les exemples incluent les publications StackOverflow suivantes :
  
  
  
  • Autofixture, créer une liste de dictionnaireavec clé alternée
  
  
  • Comment attribuer une propriété uniquement à une sous-gamme d'éléments dans une liste ?
  
  
  • Comment créer une liste de classes qui ont toujours une valeur prédéfinie définie dans AutoFixture ?
  
  

Pièces que je vois possibilité d'innovation :

• Au fur et à mesure que C # devient de plus en plus fonctionnel (correspondance de modèles, types d'enregistrement, etc.), AutoFixture fonctionnerait idéalement de plus en plus comme FsCheck et Hedgehog en F #.
• Ce serait bien si AutoFixture était capable de réifier certains concepts de test concoliques de FsCheck, comme la fonction Arb.
• Utilisez des innovations comme celles discutées dans RLCheck pour permettre aux ingénieurs de créer des entrées de test super robustes et diverses (Guid as string est un hack !) https://www.carolemieux.com/rlcheck_preprint.pdf

Je pense que certains des problèmes que je décris ici expliquent pourquoi Microsoft n'utilisera pas AutoFixture dans aucun de ses tests pour .NET Core.

Il semble qu'un fork expérimental pourrait être la voie à suivre. AutoFixture est l'un des rares projets open source que je connaisse qui est à la fois largement utilisé quotidiennement par les développeurs, peut certainement bénéficier de capacités supplémentaires et d'une facilité d'utilisation améliorée, et dispose d'une base de code de haute qualité. Je ne peux pas imaginer que l'intérêt serait faible si les inquiétudes concernant la contribution et le changement de direction étaient atténuées, ce que ferait un fork actif.

Il semble qu'un fork expérimental pourrait être la voie à suivre.

Pourquoi voudriez-vous faire ça ? Vous auriez à maintenir cette fourchette. Si vous êtes prêt à le faire, pourquoi ne pas devenir le mainteneur de ce référentiel à la place ?

Plutôt qu'un fork expérimental, j'envisagerais de créer un nouveau référentiel (ou de continuer à m'appuyer sur celui-ci) pour introduire les améliorations de la qualité de vie décrites ci-dessus.

AutoFixture a une API puissante qui peut faire beaucoup mais peut effrayer beaucoup de gens. La plupart des choses peuvent être introduites comme un simple sucre syntaxique.

pour introduire les améliorations de la qualité de vie

Renato ( @Kralizek ), que signifie QoL ? Qualité de vie?

Ouais.

Si vous êtes prêt à le faire, pourquoi ne pas devenir le mainteneur de ce référentiel à la place ?

@ploeh comment devient-on mainteneur du référentiel ? Y a-t-il des exigences?
Pour être honnête, en regardant la liste actuelle des mainteneurs, il y a de gros souliers à remplir.
J'aimerais contribuer à AutoFixture, peut-être même en tant que responsable (un jour) et je suis sûr qu'il y en a d'autres, mais j'imagine que personne ne serait accepté pour maintenir un référentiel aussi populaire.

Pourquoi voudriez-vous faire ça ? Vous auriez à maintenir cette fourchette.

Je suis d'accord avec cette citation. Lorsque j'ai initialement proposé un package expérimental, dans ce fil, je pensais à un moyen d'atténuer les problèmes rencontrés par @zvirja , tout en maintenant le référentiel. Le package aurait contenu des fonctionnalités construites au-dessus du noyau AutoFixture, et non un fork modifié. Quelque chose comme ce que @Kralizek a décrit.
Bien sûr, idéalement, un package comme celui-ci ne serait pas nécessaire. Ce que je pense que nous devrions résoudre, c'est le problème des personnes plutôt qu'un problème de technologie.

Ce que je pense que nous devrions résoudre, c'est le problème des personnes plutôt qu'un problème de technologie.

Je ne sais pas ce que cela signifie. Dis nous en plus.

Ce que je pense que nous devrions résoudre, c'est le problème des personnes plutôt qu'un problème de technologie.

Je ne sais pas ce que cela signifie. Dis nous en plus.

Je pense que ce qu'il veut dire, c'est qu'AutoFixture a besoin de mainteneurs engagés qui se sentent libres d'innover sans craindre de détruire une belle œuvre d'art, comme pour ce que @zvirja a dit dans son commentaire .

Il est difficile de se sentir engagé dans quelque chose où vous sentez que vos mains sont liées par l'ombre portée par les décisions et le leadership antérieurs.

Peu d'idées intéressantes ont été rejetées parce qu'elles étaient en conflit avec les "Anciennes Voies". Cela tuerait la motivation de quiconque. De ce point de vue, une fourchette libérerait une grande partie de ce bagage.

OK, je suis un gars simple, je veux juste des trucs comme https://github.com/AutoFixture/AutoFixture/pull/928 fusionnés. Comme je l'ai mentionné ci-dessus, AutoFixture n'a pas de bons moyens de prendre en charge la génération de valeurs uniques. Le générateur congruentiel linéaire multiplicatif semble être une bonne base pour une telle fonctionnalité. Nous avons récemment écrit le nôtre et n'étions pas aussi intelligents que quelqu'un qui connaissait cette astuce, et je n'ai trouvé le PR que plus tard.

Je suis comme, "Ouais, faisons plus de ces trucs cool."

comment devient-on mainteneur du référentiel ?

Vous déclarez essentiellement que vous êtes prêt à assumer cette responsabilité. Pour autant que je sache, j'ai toujours des droits d'administrateur sur le référentiel, et bien qu'aucun des responsables actuels n'ait explicitement déclaré cela, j'ai l'impression qu'aucun d'entre eux ne va poursuivre cela.

Y a-t-il des exigences? Pour être honnête, en regardant la liste actuelle des mainteneurs, il y a de gros souliers à remplir.

Ne vous souciez pas du passé. En ce moment, si j'ai bien lu la situation, AutoFixture est mort dans l'eau. À moins que quelqu'un ne se charge de le faire avancer, rien ne changera.

Ainsi, vous pouvez faire toutes les erreurs du monde, et vous n'aggraverez guère les choses.

@ploeh si vous le mettez comme ça, alors je serais heureux d'intervenir en tant que mainteneur et j'espère que d'autres interviendront également.

@aivascu Merci, c'est super.

Je donnerai environ 24 heures aux mainteneurs et hangarounds actuels @zvirja , @moodmosaic , @adamchester , @ecampidoglio pour commenter cela, et si je ne vois aucune protestation, je vous donnerai les droits de mainteneur.

@ploeh Aucune objection de ma part.
@aivascu Bienvenue à bord. J'espère que ce projet vous apportera le plaisir que vous recherchez 😊

@aivascu Je ne suis pas responsable mais j'adore cette bibliothèque. Envoyez-moi un ping si vous avez besoin de quelqu'un pour partager vos pensées.

@ploeh , @aivascu , ça me va :+1: :rocket:

Je suis heureux de discuter des parties de la base de code sur lesquelles j'ai travaillé, créé ou contribué. Si j'ai raté une pull request (ou un problème) où j'ai été mentionné, merci de me le faire savoir.

@aivascu Mes meilleurs vœux à vous. Mon seul conseil est que cela peut prendre environ 6 mois pour 20 000 lignes de code dans une base de code, surtout s'il n'y a pas d'"enregistrements de décision d'architecture" clairs au même endroit. Pour cette raison, sur les projets que je maintiens, j'ai commencé à les écrire pour que les gens comprennent le "style" du code. Mark les a écrits, mais principalement sur son blog et/ou StackOverflow. @moodmosaic a fait de même. Je dirais, à l'avenir, créez un dossier adr dans la racine du référentiel qui documente toute justification de conception. Vous pouvez utiliser des fichiers .md pour cela. Pour les tableaux complexes, utilisez des tableaux html plutôt que des tableaux de démarquage.

Merci à tous pour l'accueil chaleureux.
Je pense que pour le début, je vais suivre les conseils de @jzabroski et commencer à combler les lacunes dans la documentation pour faciliter l'intégration des nouveaux mainteneurs et contributeurs.
En parallèle, je peux peut-être commencer à brûler le backlog existant.
Espérons qu'il y aura plus de membres de la communauté qui se mobiliseront pour faire avancer cet outil incroyable.

Félicitations @aivascu.

Je sens que tu es le développeur principal maintenant. Je dis cela, parce que je sens que les choses reviendront à l'état "mort" qu'elles sont maintenant, dès que vous vous arrêterez - alors je vous regarde maintenant :)

J'espère que l'équipe d'Autofixture "traquera" les nouveaux membres de l'équipe, pour atténuer le risque du problème de voyage solitaire mentionné précédemment. Je suis heureux de contribuer uniquement, si quelqu'un pouvait jeter un œil à ceci https://github.com/AutoFixture/AutoFixture/pull/1164.

@aivascu Je vous ai envoyé une invitation à rejoindre l'équipe principale d'AutoFixture, mais l'invitation est toujours en attente.

@ploeh Je viens d'accepter l'invitation. Merci!

@aivascu 👍 Bienvenue dans l'équipe.

S'il y a plus que je peux faire pour vous aider, je serai heureux de le faire. Cependant, je suis inactif sur le projet depuis des années, donc je ne sais plus comment fonctionnent les éléments pratiques. J'espère que @zvirja pourra vous donner ces détails.

Merci!

Bienvenue @aivascu

@aivascu Je serais heureux de vous intégrer au projet. Si cela ne vous dérange pas, je serais vraiment heureux d'avoir une conversation vocale avec vous, afin que je puisse tout montrer et répondre aux questions. Si vous êtes d'accord, écrivez-moi un mail (vous pouvez trouver l'adresse dans les commits) afin que nous puissions nous mettre d'accord sur les détails.

Et bienvenue à nouveau.

@zvirja ce serait vraiment sympa. Je vais vous envoyer un e-mail.

Bienvenue @aivascu :+1:

Bienvenue à bord, @aivascu ! 🙂

@aivascu Étant donné que vous êtes devenu un nouveau responsable plein de passion et d'énergie pour travailler sur ce problème, devrions-nous simplement fermer et désépingler ce problème ? Une sorte de dire que pour l'instant notre avenir est déterminé ? 😄

@zvirja J'espérais un peu que quelqu'un d'autre pourrait demander à remplir les rangs des mainteneurs. 😄

Si quelqu'un pense qu'il pourrait aimer être responsable de ce référentiel, ouvrez un problème ou envoyez-nous un message.
Je vais fermer le sujet maintenant.