：recycle ：： recycle ：： recycle：このGithubの問題を印刷する前に、環境を考慮してください。 ：recycle ：： recycle ：： recycle：

裏話

@wycatsと私（およびその

それはhtmlbarのフォークとして始まりましたが、元のグリマープロジェクトなど）の構築から得られたすべての知識を抽出し、Emberのユースケースにより適したアーキテクチャを実現しましたが、将来の拡張にも柔軟に対応できるようになりました。およびその他のEmber以外のユースケース。

codezはhttps://github.com/tildeio/glimmerにあります。 TypeScriptで（再）書かれていて、かなりかっこいいと思います。 とにかく、それについてはEmberConfで

統合

エンジンでやりたい作業（主に最適化）はまだたくさんありますが、Emberの基本的なユースケースをすべてカバーするのに十分な実装ができていると思います。 そのため、約2か月前に、新しいエンジンをEmber本体に統合し始めました。 これまでの進捗状況については、このメタ問題をフォローできます。

新しいエンジンを実際のアプリで使用することはまだ不可能ですが、作業は比較的早く完了すると予想されます。 実装が完了すると、元のハンドルバーからHTMLBarへの移行と同じように、アプリの比較的簡単なドロップインアップグレードになることが期待されます。

（機能フラグを切り替える機能は、既存のすべての機能が実装される前に実行される可能性があるため、最初からアプリとシームレスに機能しない可能性があることに注意してください。）

plsはhalpを送信します

だから、あなたは「どうすれば手伝うことができるのか」と疑問に思うかもしれません。

よろしくお願いします！ ：boom ：： sparkles ：： fireworks ：： tada：

この時点で、支援するためにできる最大の価値は、既存のテストの移植を支援することです（そして、これらのPRのレビューを支援することです）。 ご覧のとおり、Emberには、「ビューレイヤー」の動作をテストする非常に広範なテストスイートがあります。 問題は、これらのテストの多くが、既存の実装と完全に結合された方法で記述されているか、サポートされなくなったレガシーセマンティクス（ {{view.foo}} ）を使用していることです。

リグレッションが発生していないことを確認するために、現在のレンダリングエンジン（「htmlbars」）とGlimmer2の両方に対してテストスイート全体を実行できるようにしたいと思います。

それを可能にする新しいテストハーネスを作成しました。 以下で技術的な詳細について説明しますが、基本的な考え方は、2つのエンジンの違いをカプセル化する抽象化レイヤーに対してテストケースを記述し、テストケース内の同じコードを両方の実装に対して実行できるようにすることです。

その過程で、プロセス内の既存のテストを「最新化」して、レガシーセマンティクスに依存しないようにします（これらのセマンティクスを明示的にテストしているように見える場合を除き、その場合はそのままにしておきます）。 また、新しいテストハーネスを使用すると、「マトリックススタイル」のテストをはるかに簡単かつ快適に行うことができます。 これについては以下で詳しく説明しますが、ここに高レベルのアーキテクチャ図があります。

最終的な結果として、テストの読みやすさと推論がはるかに簡単になり、対象範囲も大幅に拡大しました。 これは誰にとっても素晴らしい結果ですが、まだまだ多くのテストが残っており、すべてが移植されない限り、エンジンを出荷する自信はありません。 ただし、テストファイルをそれぞれ移植するのを手伝ってくれる人がいれば、来週のこの時間までに非常に良い状態になります。

ハーネスのしくみ

私たちが使用した実際のメカニズムはかなりローテクです。 聞いたことがあるかもしれませんが、シンボリックリンクと呼ばれてい

テストフォルダ内にember-glimmerパッケージには、ファイルと呼ばれるでしょうabstract-test-case.jsもシンボリックリンクされている、同じ場所内のember-htmlbarsパッケージ。 このファイルは、テストケースの作成に使用するAPIを定義します。 このファイルは両方のパッケージ間で共有（シンボリックリンク）されているため、2つの実装に固有の情報は含まれていません。

代わりに、すべての違いは、各パッケージによって提供されるファイル（ import ... from './helpers' ）をインポートすることによって抽象化されます。 あるいは、各パッケージは、 test-case.jsの「抽象」クラスの特定のメソッドをオーバーライドすることもできます（ ember-glimmerとember-htmlbarsバージョンを参照）。

（多くの場合、これらのファイルをまったく変更する必要はないかもしれませんが、それがどのように機能するか、または内部で作業が行われる場所を知っていると、問題が発生した場合でも役立つ場合があります。）

テストの仕組み

エンジンは実際のアプリのドロップインアップグレードを目的としているため、テストでこれらの機能が実際にどのように使用されるかを実際にテストしている限り、テストが実行されない理由はありません。両方のエンジン。

それがこれまでの私たちの焦点でした。 ここに例があります。

このテストは物理的にember-glimmerディレクトリ内にありますが、 ember-htmlbarsディレクトリ内の同じ場所に

ご覧のとおり、テストはこのパッケージ固有のtest-case.jsインポートしますが、それ以外の場合はレンダリングエンジンの実装に依存しません。

プロセス

一般的に、そして高レベルでは、プロセスは次のようになります。

1. ポートするテストファイルを選択します（通常、 ember-htmlbarsどこかにある既存のテストファイルです）
2. ember-glimmer/tests/integration/...どこかに新しいファイルを作成します
3. 各テストケース/モジュールを新しいファイルに移植します。
   
   
   
   • 新しいmoduleForおよびES6クラス形式の使用
   
   
   • 各テストが「INUR」サイクルを通過することを確認します（「初期レンダリング->操作なしの再レンダリング->ミューテーションによる更新->置換によるリセット」サイクル、これについては以下で詳しく説明します）
   
   
   • 重複したテスト（または上記の更新サイクルで暗黙的にカバーされているテスト）を削除（無視）します
   
   
4. 親フォルダーがすでにember-htmlbarsシンボリックリンクである場合を除き、テストをember-htmlbarsパッケージにシンボリックリンクします（上記の連結テストのように）
5. 古いファイルを削除します（移植できないテストがまだ含まれている場合を除く）
6. プルリクエストを開く
7. 確認しやすくするために、削除したテストケースごとに、理由を記載したコメントを追加します（例：/それは今を介してカバーされています/それはの複製でした/ ...）。 よくわからないテストについては、コメントや質問を自由に追加することもできます。

良いテストの書き方

テストケースを改善するために従うことができるいくつかの一般的なヒント/ルールを次に示します。

「INUR」サイクル

各テストで「INUR」サイクルを実行する必要があります。

1. 初期レンダリング

選択した初期値（ this.render(..., { ... }) ）を使用して、テストするテンプレートをレンダリングし、結果が期待どおりであることを表明します。 （例）

1. ノーオペレーションの再レンダリング

値を変更せずにthis.runTask(() => this.rerender());を呼び出し、結果が同じままであることを表明します。 （例）

1. ミューテーションによる更新

テンプレートで使用する値を更新します。 （例）

次のことを試してください。

• 意味がある場合は、更新を複数のチャンク（つまり、複数のthis.runTask +アサーション）に分割します。 これにより、値の_some_を更新すると、テンプレートの別の無関係な部分が「吹き飛ばされ」たり、その他の望ましくない影響が発生したりする「破壊」バグをキャッチする可能性が高くなります。
• 意味がある場合は、「内部変異」を使用してください。 値が単なる文字列またはその他のプリミティブ値である場合、これは問題ではありませんが、オブジェクトまたは配列を処理する場合、これは、オブジェクト/配列を維持しながら、オブジェクト/配列の「内部」の値を更新することを意味します。同じ。 （配列の例、オブジェクトの例）
• 理にかなっている場合は、さまざまな形式の「内​​部突然変異」を試してください。 これを行う方法が複数ある場合（たとえば、 pushObjectアイテムの削除など）、通常は複数の方法を試すことをお勧めします。 （例）
  
  
  
  1. 交換によるリセット
  
  

すべての変数を置き換えて、元の開始条件にリセットします。

• リセット：これは、テキストノードの元の値をキャッシュし、途中でキャッシュを更新するのを忘れたバグをキャッチするのに役立ちます。 その場合、元の値以外に変更すると問題なく動作します。 ただし、元の値に戻すと、DOMコードが短絡し、何も実行されません。
• 置換：繰り返しますが、値が文字列のような単純なプリミティブ値である場合、これは違いを生みません。 ただし、値がオブジェクト/配列などの場合、これは、そのオブジェクト/配列を別の新しいオブジェクトに置き換えることを意味します（内部値を変更するのではありません）。 （配列の例、オブジェクトの例）

テストの重複を避ける

テストケースを数回コピーして、同じもののわずかに異なるバリエーションをテストするのは簡単です（たとえば、trueとfalseで始まる{{#if foo}} 、または「POJO」とEmber.Objectの違い） ）、そして既存のテストでそれをたくさん行いました。

それが最善の方法である場合もありますが、これには多くの問題があります。 まず、ファイル内に物理的に大量のテストが生成されるため、物を見つけるのが困難になります。 また、誰かが新しいテストを追加する必要があるとき、彼らは通常、いくつかのバリアントの1つをランダムに選択し、新しいシナリオにはあまり意味のない詳細/間違いを引き継ぎます。 コピーの1つでバグを修正すると、残りの部分はおそらく忘れてしまいます。

通常、重複を回避する方法があります。 たとえば、異なる開始条件（ {{#if foo}} trueおよびfalseに対してtrue false ）をテストする場合、同じテストで両方の開始条件をテストできます。

["<strong i="5">@test</strong> if"]() {
  this.render(`{{#if cond1}}T{{else}}F{{/if}}{{#if cond2}}T{{else}}F{{/if}}`, { cond1: true, cond2: false });`

  ... // follow the usual I-N-U-R cycle
}

その他の場合、いくつかの共有スーパークラスを抽出して（実際のテストケースをスーパークラスに入れる）共有動作を定義し、サブクラスで異なる部分を構成することができました。 これにより、テストケースを一度作成すれば、さまざまなシナリオ（「マトリックススタイル」テスト）を自動的に実行できます。

最良の例は、おそらく条件テスト（ if 、 unlessなど）です。 実際のテストファイルは、テンプレート呼び出しスタイルとサブクラスTogglingSyntaxConditionalsTest （ shared-conditional-tests.jsあります）を定義するだけで、多くの共有テストを自動的に取得します。

「インラインif / unless」テストはこれをさらに進め、11（！）の異なる呼び出しシナリオに対して同じテストケースのセットを実行します。

共有の実際の構造に到達するのはやや難しく、成熟/正しくなるまでに時間がかかりましたが、その見返りは莫大でした（基本的なシナリオは現在{{#with}}と{{#each}}間で共有されています同様に）。

レガシーセマンティクス

既存のテストの多くは、ビュー、 {{view.foo}} 、 {{#view}} 、 context 、コントローラーなどのレガシーセマンティクスを使用しています。ほとんどの場合、これは単なる偶発的なものであり、それらのプリミティブが物事を行うための主な方法であった時代に書かれたテストの結果。 そのような場合、通常は問題なく新しいハーネス（代わりにコンポーネントを使用）に移植できます。

疑わしい場合は、PRの最初の反復で移植されていないテストを行い、行コメントで質問することもできます。

attrsまたはattrs

カーリーコンポーネント（ほとんどすべて）を使用するテストでは、デフォルトで{{attrs.foo}}を使用せず、同じ名前のプロパティに反映されている属性（つまり、 {{foo}}のみ）に依存することにしました。 attrs.*のテストである場合を除き（おそらくすべて同じファイルにあるはずです）、一貫性を保つために、通常は{{attrs.foo}}ではなく{{foo}}する必要があります。 曖昧さを解消する必要があると感じた場合は、いつでもinnerFooとouterFooような名前を付けることができます。

@locksによるhttps://locks.svbtle.com/to-attrs-or-not-to-attrsも参照してください。

警告

移植したテストがGlimmer2でもHTMLBarでも機能しない場合があります。 （どちらのエンジンでも機能しない場合は、おそらく何か問題があります。）

Glimmer 2で機能しない場合は、その機能がまだ完全に実装されていないことが原因である可能性があります。 （たとえば、基本的なコンポーネントのサポートを実装しましたが、現時点ではattributeBindingsを実装していません。）

この場合でも、テストを新しいスタイルに移植して、機能の実装時に簡単に有効にできるようにすることをお勧めします。 Glimmer 2のテストを一時的に無効にするには、メソッド名の@testプレフィックスを@htmlbarsに置き換えるだけです（つまり、「これをHTMLBarsのみで実行する」）。 moduleFor名前の前に@htmlbars付けることで、モジュール全体を無効にすることもできます。

まれに、テストはGlimmer 2で正しく機能しますが、HTMLBarでは合格しません。 テストしているセマンティクスが正しいことを再確認する必要がありますが、HTMLBarの現在の実装に単にバグがある可能性も十分にあります。 （これは通常、一部のHTMLBars機能を新しい「マトリックススタイル」でテストするときに発生します。一部のエッジケースでは、値が正しく更新されません。）

その場合、同様に、個々のテストケースまたはモジュール全体に@glimmerフラグを立てることができます。 これは非常にまれであると予想されるため（バグ修正が必要になる場合があります）、発生した問題の簡単な説明を行コメントに含めることができれば便利です。

例

コミュニティメンバーが既存のテストの移植を支援した優れた例をいくつか示します。

• ＃12920インライン{{if}}ヘルパー
• ＃12927 {{#with}}
• ＃13019インライン{{unless}}
• ＃13093 (hash)ヘルパー

ご覧のとおり、初期の反復はより困難でした（共有されたテストケースのストーリーをまだ理解していました）が、後者の試みは比較的簡単でした。 道を開いてくれてありがとう@GavinJoyceと@chadhietala ！

だから...どこから始めればいいの？

これが良い出発点のリストです。 これらのいずれかに取り組むことを真剣に考えている場合は、他の人がそれに取り組んでいないことを知ってもらうために、以下にコメントを残したいと思うでしょう。 （時間がなくなったり、非常に困難に遭遇した場合は、「ロックを解除」に戻ったり、WIP作業をプッシュして、他の人がそれを拾うことができるようにしてください！）

• [x] @chancancodeによる基本的なコンテンツレンダリングテスト＃13141

これがすでに存在するかどうかはわかりません。 見つけて移植してみてください。 ただし、それ以外の場合は、新しいファイルを作成してください（https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.jsで既に開始しています） 。 アイデアは、「DOMに奇妙なものを入れたらどうなるか」をテストしたいというものです。たとえば、 {{foo}} 、ここでfooはundefined 、 null 、オブジェクトなど。これは「マトリックススタイル」テストの主要なターゲットであるため、テストハーネスがどのように機能するかを調べて、条件付きテストからアイデアを引き出すことをお勧めします。

これはhttps://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.jsも吸収するはずです。

• [x] [ attr_nodesテスト]（https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/attr_nodes）（：lock： @chancancodeおよび@ wycats）

これらのテストを詳しく見て、要件を理解したいと思います。 今のところそれをロックします。

• [] [ compatテスト]（https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat）：scissors：

従来のアドオンのサポートを2.6までに終了することを発表したため、Glimmer 2でこれらの機能をサポートする必要はありません。マスターのテストと機能を削除するには、PRを開いてください。 （これには、おそらくコードベースに関する比較的深い知識が必要です。）

• [x] [ glimmer-componentテスト]（https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component）：scissors： ＃13139 by @ lorcan

このフォルダは未使用です。 削除するにはPRを送信してください。

• ヘルパー（ tests/integration/helpers移動する必要があると思います）
  
  
  
  • [] [ -html-safe ]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js）：lock ：
  
  

I'm not sure if this is needed for Glimmer 2. Locking for now.

• [x] [ closure component ]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/closure_component_test.js）（：lock：by @セラベ）

I am pretty sure this will have to be `@htmlbars` for now.

• [x] [ collectionテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/collection_test.js）：はさみ： ＃13161 @HeroicEricによる

This is legacy. Please open a PR to remove the test and any code you could find that implements the feature.

• [x] [ #componentヘルパー]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/component_test.js） ＃13140 by @GavinJoyce

Basic support for the feature has landed in #13057 and we already wrote some basic tests. Please port the rest of the tests into the new file (keep an eye for things that are already tested in the new file). I expect most of them to pass except position params which is not yet implemented in Glimmer 2 (you can make them `@htmlbars` for now).

• [x] [カスタムヘルパーテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js） ＃13138 by @zackthehuman

Basic support for the feature has landed in #12910/#13087 and we already wrote some basic tests. Please port the rest of the tests into the new file (keep an eye for things that are already tested in the new file). I expect most of them to pass with the exception of the lifecycle stuff (destroy, etc) for class-based helpers (you can make them `@htmlbars` for now).

• [x] [ debugテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/debug_test.js）：はさみ： ＃13129 @ code0100funによって

This is a duplicate of `log` as far as I can tell. See notes on `log` tests below.

• [x] [ #each-inテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_in_test.js） ＃13136 by @mmun

This should be ported to `test/intergration/syntax/...`. (In general, what was previously known as "block helpers" are now implemented as "syntax" in Glimmer 2.) 

This helper is not implemented in Glimmer 2 and will be pretty difficult for a new contributor to implement it. However, it is still important to port the tests asap (and make the module `@htmlbars`).

For bonus points, you might want to think about how to share the basic tests with the rest of the conditional matrix (i.e. testing when we need to go into the "default" branch and when we need to go into the "inverse"/`{{else}}` branch). See #13048 for some inspiration.

• [x] [ #eachテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_test.js）🔒by @ Joelkang

This should be ported to `test/intergration/syntax/...`. (In general, what was previously known as "block helpers" are now implemented as "syntax" in Glimmer 2.) 

Basic support for the feature has landed in #13048 and we already wrote some basic tests. Please port the rest of the tests into the new file (keep an eye for things that are already tested in the new file). I expect most of them to pass with the exception of the lifecycle stuff (destroy, etc) for class-based helpers (you can make them `@htmlbars` for now).

For bonus points, you might want to think about how to share the basic tests with the rest of the conditional matrix (i.e. testing when we need to go into the "default" branch and when we need to go into the "inverse"/`{{else}}` branch). I _think_ we already did that part in #13048, but if you see other ways to improve it or do more sharing please feel free to suggest them.

• [x] [ getテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/get_test.js） ＃13173 、 ＃13264 @ ro0grによって

This helper is not implemented in Glimmer 2 and will be pretty difficult for a new contributor to implement it. However, it is still important to port the tests asap (and make the module `@htmlbars`). 

(Actually, it's not _that_ hard – the implementation will likely not take more than 10-20 lines, but you would need to be quite familiar with how Glimmer 2 works to do it. Once #13103 is completed it might give you some ideas.)

• [x] [if / unless tests]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/if_unless_test.js）

I believe this is already ported by @GavinJoyce. The rest are probably just legacy stuff that we can remove. <strong i="23">@GavinJoyce</strong> can you confirm?

• [] [ {{input}}テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/input_test.js）（：lock：by @ GavinJoyce）

This helper is a not implemented in Glimmer 2 and will be pretty difficult for a new contributor to implement it. However, it is still important to port the tests asap (and make the module `@htmlbars`). 

(More precisely, the helper uses component features that are not yet implemented, such as attribute bindings. Once they are implemented the tests will probably Just Pass™.)

• [x] [ locテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/loc_test.js） ＃13129 by @ code0100fun

The helper is not implemented in Glimmer 2, but should be trivial if you want to do it. (See #12910 or #13093) Otherwise you can always mark the module as `@htmlbars`.

• [x] [ logテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/log_test.js） ＃13131 by @green -矢印

The helper is not implemented in Glimmer 2, but should be trivial if you want to do it. (See #12910 or #13093) Otherwise you can always mark the module as `@htmlbars`. As mentioned above, I think `debug_test.js` is just a duplicate of this, please verify and delete that file. **As an exception**, we only want to test initial render here, not the usual "I-N-U-R" cycle.

• [x] [ partialテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/partial_test.js） ＃13199 、 ＃13306 @jhethと@chadhietalaによる

This functionality is not implemented in Glimmer 2 and will be pretty difficult for a new contributor to implement it. However, it is still important to port the tests asap (and make the module `@htmlbars`). Please consider adding some abstractions like `this.registerPartial`.

• [x] @kiwiupoverによるtext_areaテスト＃ 13215

This helper is a not implemented in Glimmer 2 and will be pretty difficult for a new contributor to implement it. However, it is still important to port the tests asap (and make the module `@htmlbars`). 

(More precisely, the helper uses component features that are not yet implemented, such as attribute bindings. Once they are implemented the tests will probably Just Pass™.)

• [x] [ unboundテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/unbound_test.js） ＃13137 by @chadhietala

This helper is not implemented in Glimmer 2 and will be pretty difficult for a new contributor to implement it. However, it is still important to port the tests asap (and make the module `@htmlbars`). 

(Actually, it's not _that_ hard – the implementation will likely not take more than 10-20 lines, but you would need to be quite familiar with how Glimmer 2 works to do it. Once #13103 is completed it might give you some ideas.)

• [x] [ viewテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/view_test.js）（：lock：by @chadhietala）

We announced we will end support for the legacy addons by 2.6, so we won't need to support these features in Glimmer 2. Please carefully review these tests and see if there are anything that doesn't look like deprecated/legacy functionality. Otherwise, please open PRs to remove the tests and the features on master. (This would probably require relatively deep knowledge of the codebase.)

• [x] [ withテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/with_test.js）

I believe this is already ported by @chadhietala. The rest are probably just legacy stuff that we can remove. <strong i="5">@chadhietala</strong> can you confirm?

• [x] [ yieldテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/yield_test.js）（：lock：by @kiwiupover）

The feature should work in Glimmer 2 (as <strong i="12">@chadhietala</strong> pointed out in https://github.com/emberjs/ember.js/pull/13093#discussion_r55926094). Please port the rest of the tests into a new file. I expect most of them to pass. There are a lot of legacy stuff in there, so please try to understand the spirit of the test and see if they are still needed (vs they are testing a legitimate thing but just happen to use legacy semantics to test them, in which case, you should port them using non-legacy semantics).

• 「統合」テスト
  
  
  
  • [x] ["属性バインディング"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attribute_bindings_test.js）🔒 @ chadhietala ＃13481
  
  

The actual `attributeBindings` feature on components is not yet implemented, but this file doesn't seem to be testing that at all. In fact, I cannot tell what this file is testing at all. Please do investigate! (I suspect this is something we already tested, perhaps <strong i="24">@GavinJoyce</strong> or <strong i="25">@chadhietala</strong> will know.)

• [x] ["attrs_lookup"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js） ＃13203 by @Joelkang

This is probably the one place where it makes sense to test `{{attrs.foo}}` vs `{{foo}}`. I expect them to already work in Glimmer 2. However, components lifecycle hooks (e.g. `didReceiveAttrs`) is not yet implemented, so you would have to either port the test without using them, or tests that needs them as `@htmlbars` for now.

• [x] [「バインディング統合」テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js） ＃13210 by @Joelkang

Some of these tests belongs in other files (e.g. helper without parameters should be tested inside helper tests, undefined property probably belongs in the "Basic content rendering tests". The `Binding` and computed property tests are fine here, and they should Just Work™ on Glimmer to with some modernizing. (We might want to be want to be a little bit more through with CPs if this turns out to be the only place that tests them – like updating a dependent key updates the output, etc.) The view stuff seems largely incidental, you should be able to rewrite them without the legacy semantics, but there does seem to be one or two tests that are just testing legacy semantics (based on a quick scan). Please do investigate!

• [x] ["block params"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js） ＃13189 by @Joelkang

I _think_ we should be able to find a better home the stuff tested in here (like in the helpers and components files), but even just straight porting them would be helpful.

• [x] [ elementIdテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_element_id_test.js） ＃13208 by @jheth

This should be tested in https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/components/curly-components-test.js and I think it should just work in Glimmer 2. It probably doesn't make sense to test updating for this test – I don't think we support updating the `elementId`, but please do investigate!

(If we start adding more tests for components, it probably makes sense to start splitting them up into different modules/files.)

• [x] [コンポーネント呼び出しテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js） ＃12890 by @Serabe

This is the monster file that tests all things components. It should probably be tested in https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/components/curly-components-test.js, but as I said above, we probably want to start breaking things up. Some of the features are not implemented Glimmer 2 yet, so feel free to use `@htmlbars` liberally.

• [x] [コンポーネントライフサイクルテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js）（：lock： @chancancodeおよび@ wycats）

Most of these functionality are not yet implemented in Glimmer 2, so you might have to `@htmlbars` the entire module.

• [x] ["escape"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/escape_integration_test.js） ＃ 13143 by ＃13259

I _think_ we should be able to find a better home the stuff tested in here (like in the content tests file), but even just straight porting them would be helpful.

• [x] ["ヘルパールックアップ"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js）：scissors： ＃13147 by @chadhietala

I think this must already be tested in the helpers test? Please do investigate and open a PR to remove if true.

• [バツ] [ テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js）（：lock：by @paddyobrien）

This is testing the `<input>` HTML element, not the `{{input}}` helper. I won't be surprised if a lot of them doesn't work in Glimmer 2 yet, but it would be very helpful to know. Please port the test cases and flag with `@htmlbars` as needed.

• [x] ["ローカルルックアップ"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js）：scissors：

I'm not sure if this is implemented in Glimmer 2 yet. Please port the test cases and flag with `@htmlbars` as needed.

• [x] ["可変バインディング"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/mutable_binding_test.js）：lock：

The Glimmer 2 implementation might change the story a bit, locking for now.

• [x] [ selectテスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/select_in_template_test.js）：はさみ： ＃13144 @HeroicEricによる

This is legacy. Please open a PR to remove the test and any code you could find that implements the feature.

• [x] ["タグレスビュー"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js）：scissors：

I'm pretty sure this is already tested somewhere in the `if/each` tests. (The concept "tagless views" doesn't make any sense because even in htmlbars they are not implemented as views anymore.) If I am wrong, please port them into the `if/each` test files as appropriate and :scissors: this.

• [x] ["void element"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js）：はさみ： @MatrixZによる

I'm pretty sure this is already tested in the components test. (`tagName` is not implemented yet, but it doesn't seem important for the test.) If I am wrong, please port them into the curly component test files as appropriate and :scissors: this.

• [x] ["willDestroyElement"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js） （：lock：@krisseldenによる）

I don't think the `willDestroyElement` hook is implemented in Glimmer 2, but the `willDestroy` hook is (and we already have tests for them in https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/components/curly-components-test.js#L202). ~~Please investigate if there are any semantic differences (ordering, etc) between the two hooks. If they have the same semantics, we might just want to merge the two tests and test it "matrix style" (please check if the two tests are actually testing the same thing, if not, it's perfectly fine to have > 1 test).~~ Otherwise please port it with `@htmlbars`.

• [x] ["with + view"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js）：scissors： ＃13149 by @chadhietala

The `{{view}}` part is obviously legacy, if there are something that we didn't otherwise cover in the `{{#with}}` tests, please port them there, otherwise :scissors: /cc <strong i="13">@chadhietala</strong>

• [] ["ノードマネージャーの表示"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js ）：scissors ：： question：

ViewNodManagerの実装は、内部のものがまだhtmlbarのビューとして実装されているため、おそらくもう少し長く続ける必要がありますが、これは重要なことをテストしているようには見えないので、おそらく：scissors：それ？ @rwjblue確認できますか？

• 「システム」テスト
  
  
  
  • [x] ["テンプレートビューを追加"]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js）：はさみ： @chadhietalaによる
  
  

This is likely legacy. Please do investigate!

• [x] ["bootstrap"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js）：question ：： lock： @krisselden

This seems to be testing `Ember.TEMPLATES`. I don't know if this is legacy, locking for now. <strong i="11">@rwjblue</strong> can you confirm and update this item? If it's legacy, we can just :scissors: this and the implementation. If it's not, I assume it's already handled at the container/resolver level and they should Just Work™ in Glimmer 2 after porting.

• [] ["ルックアップヘルパー"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/lookup-helper_test.js）：lock：@mixonic

Please do investigate what this is testing, and see if it could be merged into the helpers integration tests.

• [x] ["render env"テスト]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js）：scissors ：： lock：https ：//github.com/emberjs/ember.js/pull/13399 @mixonic

This seems to be testing 'view.env`. I don't know if this is legacy, locking for now. @rwjblue/<strong i="22">@wycats</strong> can you confirm and update this item?

移植する必要のある他のテストもおそらくあります。 私が見逃したことに気づいたら、コメントでそれらを述べてください。

レビュー

PRを提出する準備ができたら（WIP PRを提出してください！）、PRの説明でこの問題を参照してください。確認します。

時間枠

できるだけ早く多くのテストを移植したいと考えています。 理想的には、すべてではないにしても、ほとんどのテストを1〜2週間以内に移植する必要があります。

よろしくお願いします！ ：heart ：： yellow_heart ：： green_heart ：： blue_heart ：： purple_heart：