Php-imap: IMPORTANT : Nous avons besoin de tests unitaires pour fusionner les demandes d'extraction et résoudre les problèmes (besoin d'aide)

+1 à ce projet nécessite des tests unitaires et s'il y avait des tests unitaires, chaque patch devrait être requis pour inclure des tests unitaires supplémentaires.

Cela dit, il n'y a actuellement aucun test unitaire, mais il existe de nombreux problèmes ouverts liés aux bogues et la correction des bogues l'emporte sur les tests unitaires. Ce problème ne devrait PAS empêcher la fusion des correctifs disponibles, si les PR sont suffisamment ciblés, il n'est pas difficile de voir quel sera l'impact simplement en lisant les modifications. Sans compter que la couverture du code à 100 % est une chimère dans le meilleur des cas.

La première étape consiste à réaliser que vous n'avez pas assez de temps pour entretenir ce projet par vous-même. La popularité a évidemment dépassé ce qu'un seul mainteneur peut gérer, il est peut-être temps d'envisager d'ajouter plus de mainteneurs ou même de déplacer le projet vers une équipe existante comme Respect qui compte déjà plusieurs développeurs PHP compétents et mainteneurs de projet accomplis. Cela vous ajoutera automatiquement en tant que membre et mainteneur de l'équipe Respect, ce qui devrait valoir la peine d'être pris en compte.

Ce problème ne devrait PAS empêcher la fusion des correctifs disponibles

@nickl- Désolé, mais vous voulez que je fusionne quelque chose sans aucun test ? Et s'il y avait d'autres bugs ? Et qu'en est-il de la rétrocompatibilité ?

Je sais que cette bibliothèque a de nombreux problèmes, mais dans la mesure où de nombreuses personnes l'utilisent, cela signifie qu'elles peuvent traiter les problèmes actuellement ouverts. Mais je ne veux pas fusionner quelque chose et publier sans tests appropriés pour obliger tous les utilisateurs à faire face à une rétrocompatibilité potentiellement brisée et à de nouveaux bogues.

il est peut-être temps d'envisager d'ajouter plus de mainteneurs ou même de déplacer le projet vers une équipe existante comme Respect

@nickl- Je ne connais pas l'équipe Respect et je ne veux pas être responsable de leurs changements. Et je ne comprends pas pourquoi les gars de l'équipe Respect doivent écrire des tests pour cette lib ? Ils ne l'utilisent pas (comme moi).
Vous l'utilisez, donc si vous voulez qu'il soit corrigé ou étendu dans ce référentiel, essayez simplement d'écrire quelques tests. Ce n'est pas grave en fait. Sinon, n'hésitez pas à le forker et à signaler tous les problèmes avec un lien vers votre référentiel, afin que les utilisateurs aient la possibilité d'essayer votre version, à leurs risques et périls. Mais s'il vous plaît, ne me demandez pas d'assumer la responsabilité du risque de quelqu'un en publiant quelque chose qui n'a pas pu être testé complètement.

La raison pour laquelle je ne peux pas fusionner les demandes d'extraction actuellement ouvertes est que la plupart d'entre elles rompent la compatibilité descendante et que certaines d'entre elles semblent générer de nouveaux bogues. Et je serai heureux de les fusionner tous et de sortir une nouvelle version quand il y aura des tests qui couvriront la plupart des risques possibles.

Ce problème ne devrait PAS empêcher la fusion des correctifs disponibles

Ce qui est triste, c'est que 99% des utilisateurs d'outils open source ne sont que des utilisateurs, ils n'apportent rien de précieux. Je ne sais pas pourquoi de nombreux utilisateurs s'attendent à ce que les propriétaires de référentiels DOIVENT maintenir leurs projets. Non, nous ne le faisons pas. J'ai passé 100 fois plus de temps à écrire le noyau de cet outil que quiconque a créé une pull request. Donc, vous pensez que maintenant je DOIS passer mon temps à tester des pull-requêtes qui ne me semblent même pas bonnes ? Mais je n'utilise même pas cette lib, en fait, je n'en ai pas besoin. J'ai 10 autres projets qui sont bien plus importants pour moi.

@barbushin Désolé que vous vous sentiez ainsi, j'essayais seulement d'aider.

Je suis sûr que je parle au nom de chaque utilisateur lorsque je dis : merci beaucoup pour vos efforts, nous apprécions tous grandement ce que vous avez fait jusqu'à présent et vous n'êtes certainement pas obligé de faire plus que ce que vous voulez.

Des tests automatisés seraient formidables. Je vois deux options :

1. Refactor Mailbox::imap() pour ne pas appeler les fonctions imap_* et pour être moquable.
2. Utilisez un serveur IMAP réel qui contient des appareils.

L'option 1 n'est pas impossible. À mon avis, le projet Aura gère assez bien la falsification des fonctions intégrées. Jetez un œil aux éléments Phpfunc dans

L'option 2 n'est pas un test unitaire, mais un test d'intégration. L'avantage est que la base de code actuelle peut être testée telle quelle. Par conséquent, il sera possible de vérifier si la fusion des demandes d'extraction introduirait BC dans la base de code actuelle.
La configuration du test est cependant assez complexe : il doit y avoir un serveur IMAP qui "héberge" les messages électroniques en tant que luminaires. Cette approche des tests est à mon avis plus utile pour ce projet et je peux contribuer à des cas de test avec ma profonde expérience dans ce scénario.

Quelle approche préférez-vous ?

Quant à moi, l'approche 2. ressemble à ce dont nous avons besoin.

Ensuite, nous avons besoin d'un conteneur Docker avec un serveur IMAP. Les tests unitaires enverront des e-mails à ce serveur par la fonction PHP mail() ou une autre bibliothèque, puis vérifieront les résultats attendus en y accédant à l'aide de php-imap.

J'ai vérifié, il existe des conteneurs docker avec des serveurs IMAP, et je vois également que Travis prend en charge les conteneurs docker.

Je suis d'accord!

Malheureusement, je n'ai jamais utilisé Travis auparavant et je n'ai que peu d'expérience avec Docker.

Je peux vous aider à écrire quelques tests unitaires, cependant.

Ce week-end, j'essaierai de configurer Travis avec le serveur IMAP et quelques exemples de tests. Il y aura une nouvelle branche tests , vous pouvez donc l'utiliser comme exemple et faire des pull request avec vos tests.

Comment ça se passe avec la branche tests ou les tests PHPUnit ? Voici une bonne explication, comment vous pouvez écrire vos propres tests PHPUnit : https://www.youtube.com/watch?v=k9ak_rv9X0Y

Je regarde actuellement les vidéos et j'espère pouvoir trouver du temps pour créer des tests afin de les ajouter ici.

Et voilà, @barbushin : PR #292

Pas encore grand-chose, mais mieux que rien. :)

Lorsque vous créez de nouvelles Pull Requests, assurez-vous que vous utilisez la branche develop comme base. :)

Travis CI est intégré et fonctionne. Les tests PHPUnit existent également, mais doivent être étendus et améliorés.

Il ne reste que 24 problèmes ouverts et 1 pull request ! Résolvons-les également. :)

@Sebi94nbg Que Dieu te bénisse, mec !

Il reste 12 numéros ! :)

Avec #278 et #306 j'ai besoin d'aide. Cela prend beaucoup de temps et est difficile à résoudre ou à créer une solution de contournement.

@barbushin pouvez-vous s'il vous plaît ajouter php-imap à https://codeclimate.com/quality/? Je n'ai malheureusement pas l'autorisation de le faire.

@DonaldTrump

https://codeclimate.com/github/barbushin/php-imap

[![Maintainability](https://api.codeclimate.com/v1/badges/02f72a4fd695cb7e2976/maintainability)](https://codeclimate.com/github/barbushin/php-imap/maintainability)

<a href="https://codeclimate.com/github/barbushin/php-imap/test_coverage"><img src="https://api.codeclimate.com/v1/badges/02f72a4fd695cb7e2976/test_coverage" /></a>

Merci @barbushin ! J'ai déjà ajouté ces badges au README : https://github.com/barbushin/php-imap/commit/ffee374e9f5b5867f12feb8b0096485a0780b103

Je suis malheureusement incapable de changer quoi que ce soit sur https://codeclimate.com/github/barbushin/php-imap car il est dit que je n'ai pas d'autorisations. Vous devrez donc configurer la couverture de test.

J'ai déjà validé le fichier de configuration avec les vérifications par défaut - cela devra peut-être être mis à jour : https://github.com/barbushin/php-imap/commit/5c53833ea264a777ffbdd65e5e166dd3d21b5687

Voici un identifiant de journaliste de test

4eed0d135b9e1a1668a68e5e29cc71faf872937d13c42efa4faf42papa5ed3375

Voir https://docs.codeclimate.com/docs/configuring-test-coverage

Sincères amitiés
Sergueï Barbouchine

Le mercredi 15 mai 2019 à 18h19, TS3tools [email protected] a écrit :

Merci, @barbushin https://github.com/barbushin ! j'ai déjà ajouté
ces badges au README : ffee374
https://github.com/barbushin/php-imap/commit/ffee374e9f5b5867f12feb8b0096485a0780b103

Je suis malheureusement incapable de changer quoi que ce soit à
https://codeclimate.com/github/barbushin/php-imap comme il est dit, que je
ne pas avoir d'autorisations. Vous devrez donc configurer la couverture de test.

J'ai déjà validé le fichier de configuration avec les vérifications par défaut - cela peut
doit être mis à jour : 5c53833
https://github.com/barbushin/php-imap/commit/5c53833ea264a777ffbdd65e5e166dd3d21b5687

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/barbushin/php-imap/issues/286?email_source=notifications&email_token=AAFG2WAIUTVKINH3BC4KPATPVQBHFA5CNFSM4HCQ5QP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5QP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAFG2WEUDX4DPAB43JVWWV3PVQBHFANCNFSM4HCQ5QPQ
.

@barbushin J'ai ajouté quelques configurations, mais cela ne calcule pas la couverture de code/test.

Le .travis.yml semble me convenir.

Tous les problèmes sont résolus ! :)

Maintenant, nous n'avons qu'une seule demande de fonctionnalité ouverte et un ticket pour créer une solution de contournement pour prendre en charge les recherches UTF-8 sur des serveurs Microsoft Exchange stupides.

La prochaine chose à faire est de nettoyer et d'optimiser le code pour améliorer la maintenabilité de cette bibliothèque : https://codeclimate.com/github/barbushin/php-imap/issues

Bon codage !