Ich habe dieses Thema über das automatische Testen von Plugins gefunden, aber nirgendwo erwähnt, wie man Themes oder Theme-Komponenten testet. Gibt es Beispiele dafür, wie man QUnit (oder Ähnliches) mit Themes verwendet?
Sie können es zu einem benutzerauswählbaren Theme hinzufügen oder den Testlink auf der Theme-Verwaltungsseite verwenden.
Entschuldigung, ich meinte automatisiertes Testen – ich werde meinen vorherigen Beitrag entsprechend ändern. Ich dachte an etwas wie QUnit, das einige Plugins bereits verwenden.
Nein, es ist derzeit nicht möglich, QUnit-Tests zu Themes/Komponenten hinzuzufügen…
@david, wie machbar wäre es, Unterstützung für einen /test-Ordner wie bei Plugins hinzuzufügen? Wir müssten das Theme auch aktivieren, wenn die Tests ausgeführt werden, da die Kern-Tests ohne ein Theme laufen, oder?
Das ist durchaus möglich, erfordert aber etwas Arbeit. Momentan sind alle JavaScript-Dateien des Themes in einer einzigen Datei gebündelt. Wir müssten sicherstellen, dass Tests in einem neuen, separaten Bundle untergebracht werden, damit sie nicht an normale Besucher ausgeliefert werden. Anschließend müssen wir eine Möglichkeit schaffen, QUnit-Tests für ein einzelnes Theme auszuführen.
Eine weitere Überlegung ist, dass die Route /qunit auf Produktionsservern nicht verfügbar ist. Da Themes häufig auf Produktionsservern entwickelt werden, müssen wir dies möglicherweise überdenken 
Das ist meiner Meinung nach einer der größten Nachteile von Theme-Komponenten. Sie sind super einfach bereitzustellen, was fantastisch ist, aber Tests werden oft vernachlässigt.
Wenn ich es richtig verstehe, lässt sich alles, was mit einer Theme-Komponente möglich ist, auch mit einem Plugin umsetzen. Ersteres ist einfacher zu bereitstellen, während Letzteres Tests ermöglicht.
Ja, das ist im Allgemeinen zutreffend. Am Ende kommt es auf einen Kompromiss an, je nachdem, was Sie anpassen. Zum Beispiel ließe sich das Hinzufügen eines benutzerdefinierten Stylesheets wahrscheinlich nicht einmal in einem Plugin testen. Bei der Integration von benutzerdefinierten JavaScript-Steuerelementen und Widgets wird es jedoch fraglich.
Ich habe das Gefühl, dass wir dieses Thema bei der Ember CLI-Arbeit berücksichtigen sollten. Es ist nichts Unmögliches, einen Testrunner für Themes zu haben, und wir könnten einige Grundlagen im discourse-theme-Gem liefern, um lokale Tests mit Ember CLI einzurichten.
Das Ausführen von Theme-Tests würde jedoch eine vollständige Installation von Discourse erfordern, oder? Es gibt so viele Abhängigkeiten, dass ich nicht glaube, dass wir Themes unabhängig voneinander testen könnten
Vielleicht könnte der theme-cli eine Logik enthalten, um das discourse_dev-Docker-Image zu ziehen und QUnit-Tests darin auszuführen?
Die gesamte Idee hinter Ember CLI ist, dass wir Server und Client sauber trennen. Wir könnten genügend Teile der JavaScript-Seite bereitstellen, um den Client zu testen, ohne einen Rails-Server auszuführen. Du würdest auf jeden Fall noch Node und Ember CLI installiert benötigen, aber du könntest vielleicht ohne die Installation eines vollständigen Discourse-Stacks einschließlich Redis und Postgres auskommen.
Es könnte schwierig sein, aber etwas, das wir definitiv im Hinterkopf behalten können.
Wir unterstützen jetzt Tests in Themes (späte Aktualisierung, die Unterstützung für Theme-Tests wurde Mitte 2021 hinzugefügt). Sie können in Ihrer lokalen Umgebung oder Ihrer Produktions-Website zu /theme-qunit navigieren, und alle installierten Themes/Komponenten, die Tests haben, werden dort aufgelistet. Beispiele finden Sie unter Discourse Tab Bar for Mobile oder Tag-Icons-Komponente.
Das ist großartig. Wird sich das auf das Testen von JavaScript in Plugins erstrecken?
Meinen Sie, dass Tests in der Produktion ausgeführt werden können? Das ist derzeit nur für Themes möglich.
(Lokal können Sie natürlich Plugin-JS-Tests ausführen.)
Ich denke, das Ziel wäre, sie in CI auf GitHub ausführen zu können, so wie wir es derzeit mit Specs können (sowohl Theme. als auch Plugin JS)?
Ja, wir führen Tests in CI für alle offiziellen Plugins durch.