プラグインのテスト（自動テスト）について、このトピックを見つけましたが、テーマやテーマコンポーネントのテスト方法については言及されているものに出会っていません。テーマで QUnit（または同様のもの）をどのように使用するか、例はありますか？
「いいね！」 2
ユーザーが選択できるテーマに追加するか、テーマ管理ページのテストリンクを使用してください。
申し訳ありません、自動テストのことを言いたかったのです。前の投稿を修正します。いくつかのプラグインですでに使用されている QUnit のようなものを考えていました。
「いいね！」 4
いいえ、現時点ではテーマやコンポーネントに QUnit テストを追加することはできません…
@david プラグインのように /test フォルダのサポートを追加するのはどの程度可能でしょうか？また、コアテストはテーマなしで実行されるため、テスト実行時にテーマを有効にする必要もありますよね？
「いいね！」 9
確かに可能ですが、多少の作業が必要です。現在、すべてのテーマの JavaScript ファイルは 1 つのファイルにバンドルされています。テストを新しい個別のバンドルに配置し、通常の訪問者に配信されないようにする必要があります。その後、単一のテーマに対して QUnit テストを実行する方法を確立します。もう一つ考慮すべき点は、本番サーバーでは /qunit ルートを利用できないことです。テーマは本番サーバーで開発されることが多いため、この点を見直す必要があるかもしれません 
「いいね！」 10
これは私の意見では、テーマコンポーネントの主な欠点の一つです。デプロイが非常に簡単で素晴らしいのですが、テストがおろそかになりがちです。
「いいね！」 10
私の理解が正しければ、テーマコンポーネントでできることはすべてプラグインでも可能です。前者はデプロイが簡単で、後者はテストを可能にします。
「いいね！」 2
はい、それは一般的に正確です。カスタマイズの内容によってトレードオフが生じます。例えば、カスタムスタイルシートの追加は、プラグイン内であってもテストできない可能性があります。カスタム JavaScript コントロールやウィジェットを追加する場合、その妥当性が疑問視されるようになります。
「いいね！」 6
Ember CLI の作業を行う際に、この課題を検討すべきだと感じます。テーマ用のテストランナーを用意することは決して不可能ではなく、discourse-theme gem に基本的な機能をいくつか実装して、Ember CLI を用いたローカルテストの環境を整えることも可能です。
「いいね！」 8
テーマのテストを実行するには、Discourse のフルインストールが必要になると思いますが？相互依存関係があまりにも多いため、テーマを独立してテストするのは難しいと思いますね
もしかしたら theme-cli に、discourse_dev docker イメージを取得し、その中で qunit テストを実行するロジックを組み込めるかもしれません。
「いいね！」 2
Ember CLI の根本的な考え方は、サーバーとクライアントを明確に分離することです。Rails サーバーを実行せずにクライアントをテストするために、JS 側の必要な部分のみを配布することも可能です。Node と Ember CLI のインストールは確かに必要ですが、Redis や Postgres などの完全な Discourse スタックをインストールしなくても済むかもしれません。
「いいね！」 6
少し難しいかもしれませんが、確かに心に留めておくべき点です。
「いいね！」 5
テーマでのテストをサポートするようになりました（2021年半ばにテーマテストのサポートが追加されました）。ローカル環境または本番サイトの /theme-qunit にアクセスすると、テストが含まれるインストール済みのテーマ/コンポーネントが一覧表示されます。例については、Discourse Tab Bar for Mobile または Tag icons component を参照してください。
「いいね！」 6
素晴らしいですね。これはプラグインのJavaScriptのテストにも拡張されますか？
「いいね！」 3
本番環境でテストを実行できるということですか？現時点ではテーマのみです。
（ローカルでは、もちろんプラグインのJSテストを実行できます。）
「いいね！」 1
CIで、現在specs（Theme.およびPlugin JS）で実行できるのと同様に、それらを実行できるようにすることが目標だと思いますか？
「いいね！」 2
はい、すべての公式プラグインでCIでテストを実行しています。
「いいね！」 1