Hallo! Wir möchten allen unseren Dank aussprechen, die beim Tisch des Testteams (oder beim Tisch CoreCore Core ist die Gesamtheit der Software, die zum Ausführen von WordPress erforderlich ist. Das Core-Entwicklungsteam entwickelt WordPress.:Test) beim diesjährigen WCEU Contributor Day vorbeigeschaut haben 🙇. Eure Ideen, Perspektiven und offenen Diskussionen tragen dazu bei, für das Testen von WordPress wichtige Initiativen zu fördern. Vielen Dank an alle, die teilgenommen haben!
Die Teilnehmer der Veranstaltung behandelten die folgenden Themen (auf einige davon wurde auch in #core-test in Slack verwiesen):
Vorlagen für Testberichte
- In den vorgeschlagenen Richtlinien für Testberichte sollte klargestellt werden, wie das grüne Häkchen-Emoji (✅) und das rote „X“-Emoji (❌) in Berichten verwendet werden sollten: erwartet vs. unerwartet.
- Die Vorlagen für Testberichte sollten zur Verbesserung der Lesbarkeit in Unterseiten unter einer Hauptbeschreibung „Testbericht“ im Test-Handbuch aufgeteilt werden.
- Vorschlag, Vorlagen für die Erstellung von Tickets zur Meldung von TracTrac Trac ist der Ort, an dem Mitwirkende Probleme für Fehler oder Funktionsanfragen erstellen, ähnlich wie bei GitHub.https://core.trac.wordpress.org/.-Issues bereitzustellen, ähnlich wie bei Gutenberg Issues (z. B. für Fehler im Vergleich zu Verbesserungen).
@todoUntersuchen, ob Trac vorausgefüllte Vorlagenoptionen für den ursprünglichen Beitrag und/oder Kommentare unterstützt.
Einfachere Testbeiträge
- Die Anleitung im Test-Handbuch zum Erstellen einer lokalen WordPress-Umgebung verbessern/aktualisieren.
- Der Wunsch nach kurzlebigen Testumgebungen (keine lokale InstallationLokale Installation Eine lokale WordPress-Installation ist eine Möglichkeit, durch die Installation eines LAMP- oder LEMP-Stacks auf dem eigenen Computer eine Staging-Umgebung zu erstellen. erforderlich), um PRs und Patches zu testen. Einige Ideen:
- Eine auf Core ausgerichtete Version von gutenberg.run erstellen.
- Es müsste sowohl PRs als auch einzelne Trac-Patch-Anhänge unterstützen.
- Einen ähnlichen Dienst wie den für calypso.live verwendeten nutzen.
- Eine auf Core ausgerichtete Version von gutenberg.run erstellen.
- Eine Anleitung im Test-Handbuch zum Anwenden von Patches aus GitHubGitHub GitHub ist eine Website, die eine Online-Implementierung von Git-Repositories anbietet, die von anderen Entwicklern einfach geteilt, kopiert und geändert werden können. Öffentliche Repositories können kostenlos gehostet werden, für private Repositories ist ein kostenpflichtiges Abonnement erforderlich. GitHub führte das Konzept des „Pull Requests“ ein, bei dem von Mitwirkenden in Branches vorgenommene Codeänderungen überprüft und diskutiert werden können, bevor sie vom Eigentümer des Repositorys zusammengeführt werden. https://github.com/ oder Trac hinzufügen, die verschiedene „Best-Practice“-Methoden abdeckt.
- Die Bedeutung verschiedener Umgebungsvarianten innerhalb der Gruppe der Testmitwirkenden erneut hervorheben (Docker/
wp-env, VVV, Laravel Valet, Local usw.). Es sollte keine Präferenz für „die beste“ oder „eine Möglichkeit“ geben, WordPress auszuführen/zu testen, da dies die reale Vielfalt innerhalb der WordPress-Community widerspiegeln sollte. - Eine neue
week-in-test–KategorieKategorie Die Taxonomie „Kategorie“ ermöglicht es, Beiträge/Inhalte mit einer gemeinsamen Verbindung zusammenzufassen. Kategorien sind vordefiniert und weit gefasst. für Beiträge zur Testwoche zuzuweisen, um das Filtern nach einem „Einstiegspunkt“ ins Testen zu erleichtern (derzeit werden sie unter der allgemeinerensummary-Kategorie zusammengefasst).
End-to-End-Tests (E2E)
- Fragen dazu, wo mit E2E-Tests in WordPress begonnen werden sollte:
- Es wurde auf die Bemühungen zur Migration von Playwright-E2E-Tests verwiesen.
- E2E-Mitwirkende wurden ermutigt, sich in #core-test und #core-editor nach aktuellen Informationen zu erkundigen sowie die Teilnehmer früherer Diskussionen zu kontaktieren.
- Es wurde angemerkt, dass E2E-Tests häufig sporadisch fehlschlagen, was die Entwicklung verwirren und behindern kann. Dies wird oft unerwarteten Verzögerungen bei DOM-Aktualisierungen zugeschrieben.
- Es sollte berücksichtigt werden, dass E2E-Tests BarrierefreiheitBarrierefreiheit Barrierefreiheit (häufig als a11y abgekürzt) bezeichnet die Gestaltung von Produkten, Geräten, Dienstleistungen oder Umgebungen für Menschen mit Behinderungen. Das Konzept des barrierefreien Designs gewährleistet sowohl „direkten Zugang“ (d. h. ohne Unterstützung) als auch „indirekten Zugang“, also die Kompatibilität mit unterstützenden Technologien einer Person (zum Beispiel Bildschirmleseprogrammen). (https://en.wikipedia.org/wiki/Accessibility) („a11yBarrierefreiheit Barrierefreiheit (häufig als a11y abgekürzt) bezeichnet die Gestaltung von Produkten, Geräten, Dienstleistungen oder Umgebungen für Menschen mit Behinderungen. Das Konzept des barrierefreien Designs gewährleistet sowohl „direkten Zugang“ (d. h. ohne Unterstützung) als auch „indirekten Zugang“, also die Kompatibilität mit unterstützenden Technologien einer Person (zum Beispiel Bildschirmleseprogrammen). (https://en.wikipedia.org/wiki/Accessibility)“) als positiven Nebeneffekt passiv validieren können.
- Einen E2E-Abschnitt zur Testwoche hinzufügen, um das Bewusstsein für diesen Aspekt des WordPress-Testens zu erhöhen.
Änderung der Uhrzeit der Dienstagstreffen
- Es wurde vorgeschlagen, die Dienstagstreffen für
<test-chat>und<test-triage>von 17:00 auf 16:00 UTC zu verlegen, um eine breitere Teilnahme europäischer Mitwirkender zu ermöglichen. Bitte teilt hier eure Stimme oder Gedanken mit.
Dank an @boniu91 für das Peer-Review dieses Beitrags.