TDD est-il viable dans les projets collaboratifs open source

Disons que je voulais démarrer un projet open source qui j'espère / m'attends à ce que beaucoup de gens soumettent des correctifs et ainsi de suite. Est-il viable d'adopter une approche TDD stricte? Puis-je / dois-je m'attendre à ce que les collaborateurs écrivent des tests de qualité chaque fois qu'ils soumettent un patch?

Une chose à laquelle j'ai pensé est d'écrire des suites de tests pour les rapports de bogues individuels et les demandes de fonctionnalités et d'exiger que tous les correctifs / demandes d'extraction fassent passer les tests, mais à ce stade, il semble qu'il serait préférable d'écrire la fonctionnalité / correction de bogue moi même.

Pour autant que je sache, la plupart des grands projets open source qui utilisent TDD (ou au moins écrivent des tests) semblent être principalement écrits uniquement par un individu ou une équipe, où il est facile d'appliquer des pratiques telles que TDD.

open-source tdd collaboration

— DormoTheNord
source

Partager vos recherches aide tout le monde. Dites-nous ce que vous avez essayé et pourquoi cela n'a pas répondu à vos besoins. Cela démontre que vous avez pris le temps d'essayer de vous aider, cela nous évite de réitérer des réponses évidentes, et surtout vous aide à obtenir une réponse plus spécifique et pertinente. Voir aussi How to Ask

— gnat

@gnat J'ai recherché StackExchange, et il y a eu quelques questions où les gens demandent des exemples de projets open source avec des tests unitaires, ce qui n'est pas la même que ma question. Conformément à votre demande, j'ai ajouté quelques informations supplémentaires.

— DormoTheNord

DormoTheNord, je crois que @gnat signifiait des exemples spécifiques et cités .

— haneefmubarak

"il serait préférable d'écrire moi-même la fonction / correction de bogue." Avec ou sans tests? Êtes-vous un partisan de TDD ou vérifiez-vous simplement si cela est viable dans ce contexte?

— JeffO

Bien sûr, vous pouvez / devez vous attendre à ce que les collaborateurs écrivent des tests de qualité chaque fois qu'ils soumettent un correctif. Ce n'est pas seulement bénéfique - c'est extrêmement courant dans les grands projets open source aujourd'hui (je peux donner des exemples si vous le souhaitez).

— Benjamin Gruenbaum

Réponses:

Vous ne pouvez pas vraiment appliquer une approche TDD (test en premier) sur un projet open source où les correctifs peuvent être soumis par le grand public.

Ce que vous pouvez appliquer, c'est que tous les correctifs doivent avoir un ensemble de cas de test pour les correctifs inclus dans le correctif et que ces cas de test, ainsi que tous les cas de test existants, doivent réussir. Vous pouvez appliquer cela en ne donnant des droits de validation qu'à quelques développeurs de confiance connus pour utiliser et accepter les politiques du projet et en déclarant publiquement que les soumissions / pull-demandes ne seront incorporées que si elles sont accompagnées de cas de test réussis (avec couverture suffisante).

Cela ne garantit pas que le test est écrit en premier , mais il garantit que le test est écrit .

— Bart van Ingen Schenau
source

Le propriétaire du référentiel peut-il refuser de retirer des modifications qui ne sont pas conformes aux normes de qualité du projet? Peut-être que la qualité et la quantité des contributions en souffriraient si les contributeurs n'aimaient pas ceci, mais cela; cela ne veut pas dire que vous ne pouvez pas les appliquer. Sûrement?

— Tom W

@TomW: Comment vérifieriez-vous que ma soumission est créée selon les pratiques TDD et non, par exemple, avec les tests écrits après la mise en œuvre?

— Bart van Ingen Schenau

Ah, je vois ce que tu veux dire. Je suppose qu'une certaine perte de rigueur est inévitable, mais vous pouvez toujours vérifier que le code est livré avec des tests, que les tests sont suffisamment granulaires et qu'ils couvrent tout ce qu'ils sont censés faire. Je ne connais pas très bien git, mais pour une demande de pull donnée, est-il possible d'inspecter la séquence de commits pour cet ensemble de modifications pour voir que le développeur a suivi un processus approprié pour le produire?

— Tom W

En d'autres termes, vous ne pouvez pas confirmer son processus interne, mais vous pouvez vous assurer que la sortie de celui-ci répond à une certaine norme. Exiger des tests et s'assurer que la conception est logique relève du pouvoir du propriétaire.

— Adrian Schneider

Vous pouvez demander aux utilisateurs de soumettre des correctifs de test uniquement avant d'être autorisés à travailler sur le code; cela fournirait une occasion supplémentaire de revoir la conception prévue avant que le code lui-même ne soit écrit.

Dans la pratique, cela peut tuer tout enthousiasme des gens pour leur contribution au projet - ou cela peut enflammer ceux qui sont d'accord avec votre méthodologie.

Les examinateurs devraient cependant être très compétents pour contourner rapidement les revues de conception, afin de ne pas retarder le développement.

— Alex Feinman
source