DocsWP — WordPress Help

Notes de terrain de la journée des contributeurs de la WCEU 2022

Bonjour ! Nous aimerions exprimer notre gratitude à toutes les personnes qui se sont arrêtées à la table de l’équipe Test (ou de CoreCore Core est l’ensemble des logiciels nécessaires pour exécuter WordPress. L’équipe de développement de Core construit WordPress.:Test) lors du Contributor Day du WCEU de cette année 🙇. Vos idées, vos points de vue et vos discussions ouvertes contribuent à favoriser des initiatives essentielles pour tester WordPress. Merci à toutes les personnes qui ont participé !

Les participants à l’événement ont abordé les sujets suivants (dont certains ont également été évoqués dans #core-test sur Slack) :

Modèles de rapports de test

  • Dans les directives proposées pour les rapports de test, préciser comment les émojis représentant une coche verte (✅) et un « X » rouge (❌) doivent être utilisés dans les rapports : attendu ou inattendu.
  • Détailler les modèles de rapports en sous-pages sous une description principale « Rapport de test » dans le manuel de test afin d’améliorer la lisibilité.
  • Proposition de fournir des modèles de création de tickets pour le signalement de problèmes dans TracTrac Trac est l’endroit où les contributeurs créent des problèmes pour des bogues ou des demandes de fonctionnalités, à l’instar de GitHub.https://core.trac.wordpress.org/., similaires aux problèmes Gutenberg (par exemple pour les bogues ou les améliorations).
    • @todo Vérifier si Trac prend en charge des options de modèles préremplies, pour le message initial et/ou les commentaires.

Contributions aux tests facilitées

  • Améliorer/mettre à jour les instructions du manuel de test pour créer un environnement WordPress local.
  • Le souhait de disposer d’environnements de test éphémères (aucune installation localeInstallation locale Une installation locale de WordPress permet de créer un environnement de préproduction en installant une pile LAMP ou LEMP sur son ordinateur local. nécessaire) pour tester les PR et les correctifs. Quelques idées :
    • Créer une version ciblée sur Core de gutenberg.run.
      • Il faudrait prendre en charge à la fois les PR et les pièces jointes individuelles de correctifs Trac.
    • Utiliser un service similaire à celui utilisé pour calypso.live.
  • Ajouter au manuel de test des instructions pour appliquer des correctifs depuis GitHubGitHub GitHub est un site web qui propose une mise en œuvre en ligne de dépôts git pouvant facilement être partagés, copiés et modifiés par d’autres développeurs. Les dépôts publics sont gratuits à héberger, tandis que les dépôts privés nécessitent un abonnement payant. GitHub a introduit le concept de « pull request », grâce auquel les modifications de code effectuées dans des branches par les contributeurs peuvent être examinées et discutées avant d’être fusionnées par le propriétaire du dépôt. https://github.com/ ou Trac, en couvrant les différentes méthodes recommandées.
  • Rappeler l’importance de la diversité des environnements parmi le groupe de contributeurs aux tests (Docker/wp-env, VVV, Laravel Valet, Local, etc.). Il ne devrait pas y avoir de préférence pour « le meilleur » ou « une seule manière » d’exécuter/tester WordPress, puisque cela devrait refléter la diversité réelle de la communauté WordPress.
  • Attribuer une nouvelle week-in-test catégorieCatégorie La taxonomie « catégorie » permet de regrouper des articles ou du contenu partageant un lien commun. Les catégories sont prédéfinies et larges. aux articles Week in Test, afin de faciliter le filtrage de « par où commencer » pour les tests (ils sont actuellement regroupés sous la catégorie plus générique summary).

Tests de bout en bout (E2E)

  • Questions concernant le point de départ des tests E2E dans WordPress :
  • Il a été observé qu’il est courant que les tests E2E échouent de manière intermittente, ce qui peut semer la confusion et entraver le développement. Cela est souvent attribué à des retards inattendus dans la mise à jour du DOM.
  • Considérer que les tests E2E peuvent valider passivement l’accessibilitéAccessibilité L’accessibilité (couramment abrégée en a11y) désigne la conception de produits, d’appareils, de services ou d’environnements destinés aux personnes en situation de handicap. Le concept de conception accessible garantit à la fois un « accès direct » (c’est-à-dire sans assistance) et un « accès indirect », c’est-à-dire la compatibilité avec les technologies d’assistance d’une personne (par exemple, les lecteurs d’écran). (https://en.wikipedia.org/wiki/Accessibility) (« a11yAccessibilité L’accessibilité (couramment abrégée en a11y) désigne la conception de produits, d’appareils, de services ou d’environnements destinés aux personnes en situation de handicap. Le concept de conception accessible garantit à la fois un « accès direct » (c’est-à-dire sans assistance) et un « accès indirect », c’est-à-dire la compatibilité avec les technologies d’assistance d’une personne (par exemple, les lecteurs d’écran). (https://en.wikipedia.org/wiki/Accessibility) ») comme effet bénéfique secondaire.
  • Ajouter une section E2E à la Week in Test afin de mieux faire connaître cet aspect des tests WordPress.

Changement d’horaire des réunions du mardi

  • Il a été suggéré que les réunions du mardi pour <test-chat> et <test-triage> passent de 17 h à 16 h UTC afin de permettre une participation plus large des contributeurs européens. Partagez votre vote ou vos réflexions ici.

Merci à @boniu91 pour la relecture de cet article.

#meeting-notes