: recycle:: recycle:: recycle: Harap pertimbangkan lingkungan sebelum mencetak edisi Github ini. : daur ulang:: daur ulang:: daur ulang:

The Backstory

@wycats dan saya (dan banyak orang lain yang telah membantu selama ini) telah mengerjakan pembangunan kembali mesin rendering selama enam bulan terakhir, dengan nama sandi "Glimmer 2".

Ini dimulai sebagai cabang dari proyek glimmer asli , dll), menghasilkan arsitektur yang secara bersamaan lebih sesuai untuk kasus penggunaan Ember tetapi juga lebih fleksibel dan ditempatkan dengan baik untuk ekstensi di masa mendatang dan kasus penggunaan non-Ember lainnya.

Anda dapat menemukan codez di https://github.com/tildeio/glimmer. Ini (ulang) ditulis dalam TypeScript, dan saya pikir itu cukup keren. Lebih lanjut tentang itu di EmberConf .

Integrasi

Meskipun masih banyak pekerjaan (kebanyakan pengoptimalan) yang ingin kami lakukan pada mesin, kami yakin kami telah menerapkan cukup untuk mencakup semua kasus penggunaan dasar Ember. Jadi sekitar dua bulan lalu , kami telah mulai mengintegrasikan mesin baru ke Ember. Anda dapat mengikuti masalah meta ini untuk kemajuan kita sejauh ini.

Meskipun belum memungkinkan untuk menggunakan mesin baru di aplikasi nyata, kami berharap pekerjaan tersebut akan segera selesai. Harapannya adalah setelah kami menyelesaikan penerapan, ini akan menjadi peningkatan versi drop-in yang relatif tidak menyakitkan untuk aplikasi, seperti migrasi Handlebars ke HTMLBars asli.

(Perlu diperhatikan bahwa kemampuan untuk mengubah tanda fitur mungkin akan membuat _sebelum_ semua fitur yang ada diimplementasikan, jadi mungkin _not_ berfungsi dengan lancar dengan aplikasi Anda sejak awal.)

Tolong kirim halp

Jadi, Anda mungkin bertanya-tanya, "Apa yang bisa saya bantu?"

Saya senang Anda bertanya! : boom:: berkilau:: kembang api:: tada:

Pada titik ini, nilai tertinggi yang dapat Anda lakukan untuk membantu adalah membantu port pengujian yang ada (dan membantu meninjau PR ini). Anda lihat, Ember memiliki rangkaian pengujian yang cukup ekstensif yang menguji perilaku "lapisan tampilan". Masalahnya adalah banyak dari pengujian ini ditulis dengan cara yang cukup digabungkan dengan implementasi yang ada atau menggunakan semantik lama (seperti {{view.foo}} ) yang tidak lagi didukung.

Untuk memastikan bahwa kami tidak menyebabkan regresi apa pun, kami ingin menjalankan seluruh rangkaian pengujian kami terhadap mesin rendering saat ini ("htmlbars") dan Glimmer 2.

Kami telah menulis test harness baru yang memungkinkan kami melakukan hal itu. Saya akan membahas detail teknis di bawah ini, tetapi ide dasarnya adalah bahwa kami telah menulis kasus pengujian kami terhadap lapisan abstraksi yang merangkum perbedaan antara kedua mesin, memungkinkan kode yang sama dalam kasus pengujian untuk dijalankan terhadap kedua implementasi.

Sepanjang jalan, kami juga "memodernisasi" pengujian yang ada dalam proses untuk tidak mengandalkan semantik lama (kecuali jika pengujian tersebut tampaknya secara eksplisit menguji semantik tersebut, dalam hal ini kami akan membiarkannya). Harness pengujian baru kami juga membuatnya lebih mudah dan lebih menyenangkan untuk melakukan pengujian "gaya matriks". Lebih lanjut tentang itu di bawah, tetapi berikut adalah diagram arsitektur tingkat tinggi:

Hasil akhirnya adalah bahwa tes sekarang jauh lebih mudah untuk dibaca dan dipertimbangkan, dan kami juga meningkatkan cakupannya. Ini adalah hasil yang bagus untuk semua orang, tetapi kami masih memiliki lebih banyak tes lagi, dan kami tidak dapat merasa percaya diri untuk mengirimkan mesin tanpa semuanya diangkut. Namun, jika beberapa dari Anda dapat membantu kami mem-port file pengujian masing-masing, kami akan berada dalam kondisi yang sangat baik minggu depan!

Bagaimana harness bekerja

Mekanisme sebenarnya yang kami gunakan adalah teknologi yang cukup rendah. Anda mungkin pernah mendengarnya, ini disebut tautan simbolik .

Di dalam folder percobaan ember-glimmer package, Anda akan menemukan file bernama abstract-test-case.js , yang juga terhubung ke lokasi yang sama di dalam paket ember-htmlbars . File ini mendefinisikan API yang kami gunakan untuk menulis kasus uji. Karena file ini digunakan bersama (symlink) antara kedua paket, file ini tidak berisi sesuatu yang spesifik tentang kedua implementasi tersebut.

Sebaliknya, semua perbedaan diabstraksi dengan mengimpor file (seperti import ... from './helpers' ) yang disediakan oleh setiap paket. Sebagai alternatif, setiap paket juga dapat menimpa metode tertentu pada kelas "abstrak" di test-case.js (lihat versi ember-glimmer vs ember-htmlbars ).

(Dalam banyak kasus, Anda bahkan mungkin tidak perlu memodifikasi file-file ini sama sekali, tetapi mengetahui cara kerjanya / di mana pekerjaan terjadi secara tersembunyi mungkin masih berguna jika Anda mengalami masalah.)

Bagaimana tesnya bekerja

Karena mesin dimaksudkan sebagai peningkatan drop-in untuk aplikasi nyata, selama pengujian kami benar-benar menguji bagaimana fitur-fitur ini seharusnya digunakan di dunia nyata, tidak ada alasan mengapa pengujian tidak berjalan dengan kedua mesin.

Itulah fokus kami sejauh ini. Anda bisa melihat contohnya di sini .

Tes ini secara fisik terletak di dalam direktori ember-glimmer , tetapi terhubung ke lokasi yang sama di direktori ember-htmlbars (pada kenyataannya, seluruh direktori terhubung dengan symlink).

Seperti yang Anda lihat, tes ini mengimpor paket khusus test-case.js , tetapi sebaliknya adalah agnostik tentang implementasi mesin rendering.

Proses

Secara umum, dan pada tingkat tinggi, prosesnya terlihat seperti ini:

1. Pilih file tes ke port (biasanya itu adalah file tes yang ada di suatu tempat di ember-htmlbars )
2. Buat file baru di dalam ember-glimmer/tests/integration/... suatu tempat
3. Port setiap kasus / modul uji ke file baru, sementara ...
   
   
   
   • Menggunakan format kelas moduleFor dan ES6 baru
   
   
   • Memastikan bahwa setiap pengujian melalui siklus "INUR" ("render awal -> render ulang tanpa operasi -> perbarui melalui mutasi -> setel ulang melalui siklus", lebih lanjut tentang ini di bawah)
   
   
   • Menghapus (mengabaikan) tes duplikat (atau tes yang secara implisit tercakup dalam siklus pembaruan yang disebutkan di atas)
   
   
4. Symlink tes kembali ke paket ember-htmlbars , kecuali folder induk sudah menjadi symlink di ember-htmlbars (seperti tes concat yang saya tunjukkan di atas)
5. Hapus file lama (kecuali jika masih berisi beberapa tes yang tidak dapat dilakukan porting)
6. Buka permintaan tarik
7. Untuk memudahkan peninjauan, tambahkan komentar baris untuk setiap kasus uji yang Anda hapus, yang menyatakan alasannya (mis./ sekarang ditutupi melalui/ itu adalah duplikasi dari/ ...). Anda juga dapat dengan bebas menambahkan komentar / pertanyaan pada tes yang tidak Anda yakini.

Bagaimana menulis tes yang bagus

Berikut adalah beberapa tip / aturan umum yang dapat Anda ikuti untuk meningkatkan kasus pengujian.

Siklus "INUR"

Kami ingin setiap tes melalui siklus "INUR":

1. Render awal

Render template yang ingin Anda uji, dengan nilai awal pilihan Anda ( this.render(..., { ... }) ) dan tegaskan bahwa hasilnya adalah yang Anda harapkan. ( Contoh )

1. Rendering ulang tanpa operasi

Panggil this.runTask(() => this.rerender()); tanpa perubahan apa pun pada nilainya, lalu tegaskan bahwa hasilnya tetap sama. ( Contoh )

1. Pembaruan melalui mutasi

Lakukan beberapa pembaruan pada nilai yang Anda gunakan di template. ( Contoh )

Anda harus mencoba untuk:

• Bagi pembaruan menjadi beberapa bagian (yaitu, beberapa pernyataan this.runTask +) jika masuk akal. Hal ini meningkatkan peluang untuk menangkap bug "clobbering" di mana memperbarui _some_ nilai akan "menerbangkan" bagian lain yang tidak terkait dari template atau menyebabkan efek lain yang tidak diinginkan.
• Gunakan "mutasi interior" jika masuk akal. Ketika nilai hanya berupa string atau nilai primitif lainnya, ini tidak masalah, tetapi ketika Anda berurusan dengan objek atau larik, ini berarti memperbarui nilai "di dalam" objek / larik sambil mempertahankan objek / larik tersebut sama. ( Contoh Array , Contoh Objek )
• Cobalah berbagai bentuk "mutasi interior" jika itu masuk akal. Jika ada lebih dari satu cara untuk melakukan ini (mis. pushObject vs menghapus item, dll), biasanya ide yang baik untuk mencoba lebih dari satu cara. ( Contoh )
  
  
  
  1. Setel ulang melalui penggantian
  
  

Setel ulang ke kondisi awal asli dengan mengganti semua variabel.

• Reset: ini membantu untuk menangkap bug di mana kami menyimpan nilai asli dari node teks dan lupa memperbarui cache di sepanjang jalan. Dalam hal ini, ketika Anda mengubahnya menjadi apa pun selain nilai aslinya, itu akan berfungsi dengan baik; tetapi bila Anda mengubahnya kembali ke nilai aslinya, kode DOM akan mengalami korsleting dan tidak melakukan apa pun.
• Penggantian: sekali lagi, jika nilainya adalah nilai primitif sederhana seperti string, maka ini tidak membuat perbedaan. Tetapi jika nilainya adalah objek / larik, dll, ini berarti mengganti objek / larik itu dengan objek baru lainnya (sebagai lawan mutasi nilai internalnya). ( Contoh Array , Contoh Objek )

Hindari menggandakan tes

Mudah untuk menyalin kasus uji beberapa kali untuk menguji variasi yang sedikit berbeda dari hal yang sama (mis. {{#if foo}} dimulai dengan benar vs salah, atau perbedaan antara "POJO" vs Ember.Object ), dan kami telah melakukan banyak hal dalam pengujian yang ada.

Terkadang itulah yang terbaik yang dapat Anda lakukan, tetapi ada banyak masalah dengan ini. Pertama, ia menghasilkan sejumlah besar tes secara fisik dalam file, sehingga sulit untuk menemukan sesuatu. Juga, ketika seseorang perlu menambahkan tes baru, mereka biasanya akan secara acak memilih salah satu dari sedikit varian, membawa detail / kesalahan yang tidak terlalu masuk akal untuk skenario baru. Saat kami memperbaiki bug di salah satu salinan, kami mungkin akan melupakan sisanya.

Biasanya, ada cara untuk menghindari duplikasi. Misalnya, dalam kasus pengujian kondisi awal yang berbeda ( {{#if foo}} melawan true dan false ), Anda dapat menguji kedua kondisi awal dalam pengujian yang sama:

["<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
}

Dalam kasus lain, kami dapat mendefinisikan perilaku bersama dengan mengekstrak beberapa kelas super bersama (meletakkan kasus pengujian aktual di kelas super), dan mengonfigurasi bagian-bagian yang berbeda di subkelas. Hal ini memungkinkan Anda untuk menulis kasus pengujian satu kali, dan secara otomatis menjalankannya dalam banyak skenario yang berbeda (pengujian "Gaya Matriks").

Contoh terbaik mungkin adalah tes kondisional ( if , unless , dll). File pengujian sebenarnya hanya mendefinisikan gaya pemanggilan template dan subkelas TogglingSyntaxConditionalsTest (terletak di shared-conditional-tests.js ) dan secara otomatis mendapatkan banyak pengujian bersama.

Pengujian "inline if / kecuali" mengambil tindakan ini lebih jauh, menjalankan kumpulan kasus pengujian yang sama terhadap 11 (!) Skenario pemanggilan yang berbeda.

Struktur sebenarnya dari pembagian agak sulit untuk sampai pada, dan membutuhkan beberapa waktu untuk matang / menjadi benar, tetapi hasilnya sangat besar (skenario dasar sekarang dibagi antara {{#with}} dan {{#each}} demikian juga).

Semantik lama

Banyak pengujian yang ada menggunakan semantik lama seperti tampilan, {{view.foo}} , {{#view}} , context , pengontrol, dll. Sering kali, ini murni insidental, dan hanya hasil tes ditulis dalam waktu di mana para primitif itu adalah cara utama untuk melakukan sesuatu. Dalam kasus tersebut, Anda biasanya dapat mem-portnya ke harness baru (yang menggunakan komponen sebagai gantinya) tanpa masalah.

Jika ragu, Anda juga dapat menguji unported di iterasi pertama PR Anda dan mengajukan pertanyaan Anda di baris komentar.

Untuk attrs atau tidak ke attrs

Kami memutuskan untuk default untuk tidak menggunakan {{attrs.foo}} dalam tes yang menggunakan komponen keriting (yang hampir semuanya) dan lebih mengandalkan hanya mengandalkan atribut yang direfleksikan ke properti dengan nama yang sama (yaitu hanya {{foo}} ). Kecuali pengujian secara khusus _about_ menguji attrs.* (semuanya mungkin ada dalam file yang sama), Anda biasanya lebih memilih {{foo}} daripada {{attrs.foo}} untuk konsistensi. Anda selalu dapat menamai hal-hal seperti innerFoo vs outerFoo jika Anda merasa perlu untuk menjelaskan.

Lihat juga https://locks.svbtle.com/to-attrs-or-not-to-attrs oleh @locks.

Peringatan

Terkadang pengujian yang Anda porting mungkin tidak berfungsi baik pada Glimmer 2 atau HTMLBars. (Jika tidak berhasil pada kedua mesin, Anda mungkin melakukan kesalahan.)

Dalam kasus di mana itu tidak berfungsi pada Glimmer 2, itu mungkin karena kami belum menerapkan fitur itu sepenuhnya. (Misalnya, kami telah menerapkan dukungan komponen dasar tetapi belum menerapkan attributeBindings pada saat ini.)

Dalam kasus ini, masih bagus untuk mem-port pengujian ke gaya baru, sehingga kita dapat mengaktifkannya dengan mudah saat fitur diimplementasikan. Untuk menonaktifkan tes sementara untuk Glimmer 2, Anda cukup mengganti awalan @test dalam nama metode menjadi @htmlbars (yang berarti "jalankan ini hanya di HTMLBars"). Anda juga dapat menonaktifkan seluruh modul dengan mengawali moduleFor name dengan @htmlbars .

Dalam beberapa kasus yang jarang terjadi, pengujian akan bekerja dengan benar di Glimmer 2 tetapi tidak lolos di HTMLBars. Anda harus memeriksa ulang apakah semantik yang Anda uji sudah benar, tetapi mungkin juga ada bug dalam implementasi HTMLBars saat ini. (Ini biasanya terjadi saat kami menguji beberapa fitur HTMLBars dengan "gaya matriks" baru, yang nilainya tidak diperbarui dengan benar di beberapa kasus edge.)

Dalam kasus ini, Anda juga dapat menandai kasus uji individu atau seluruh modul sebagai @glimmer . Karena ini diharapkan cukup jarang (dan mungkin memerlukan perbaikan bug), akan sangat membantu jika Anda dapat memasukkan deskripsi singkat tentang masalah yang Anda hadapi dalam komentar baris.

Contoh

Berikut adalah beberapa contoh bagus di mana anggota komunitas kami telah membantu port pengujian yang ada:

• # 12920 Sebaris {{if}} pembantu
• # 12927 {{#with}}
• # 13019 Sebaris {{unless}}
• # 13093 (hash) pembantu

Seperti yang Anda lihat, iterasi sebelumnya lebih sulit (kami masih mencari tahu kisah kasus uji bersama), tetapi upaya terakhir relatif mudah. Terima kasih @GavinJoyce dan @chadhietala karena telah membuka jalan!

Jadi ... darimana saya mulai?

Berikut adalah daftar titik awal yang baik. Jika Anda serius untuk mengerjakan salah satunya, Anda mungkin ingin meninggalkan komentar di bawah ini sehingga orang lain tahu untuk tidak mengerjakannya. (Jika Anda kehabisan waktu atau mengalami kesulitan besar, silakan kembali untuk "membuka kunci" dan / atau mendorong pekerjaan WIP Anda, sehingga orang lain dapat mengambilnya!)

• [x] Pengujian rendering konten dasar # 13141 oleh @chancode

Saya tidak tahu apakah ini sudah ada. Silakan coba temukan dan port jika ya. Tetapi sebaliknya, buat file baru untuknya (kami sudah memulai sesuatu di https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js) . Idenya adalah kami ingin menguji "apa yang terjadi jika Anda memasukkan sesuatu yang aneh ke DOM", misalnya {{foo}} , di mana foo adalah undefined , null , dan objek, dll. Ini adalah target utama untuk pengujian "Matrix Style", jadi Anda mungkin ingin mempelajari cara kerja test harness dan menarik ide dari pengujian kondisional.

Ini juga harus menyerap https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js juga.

• [x] [ attr_nodes tes] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/attr_nodes) (: lock: oleh @chancancode dan @ wycats)

Kami ingin melihat lebih dekat pada tes ini dan memahami persyaratannya. Menguncinya untuk saat ini.

• [] [ compat tes] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat): gunting:

Kami mengumumkan bahwa kami akan menghentikan dukungan untuk addons lama pada 2.6, jadi kami tidak perlu mendukung fitur ini di Glimmer 2. Buka PR untuk menghapus tes dan fitur pada master. (Ini mungkin membutuhkan pengetahuan yang relatif dalam tentang basis kode.)

• [x] [tes glimmer-component ] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component): gunting: # 13139 oleh @ lorcan

Folder ini tidak digunakan. Silakan kirim PR untuk menghapusnya.

• Pembantu (saya pikir kita harus memindahkan mereka ke tests/integration/helpers )
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js): kunci :
  
  

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) (: kunci: oleh @ Serabe)

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

• [x] [tes collection ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/collection_test.js): gunting: # 13161 oleh @HeroicEric

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

• [x] [ #component helper] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/component_test.js) # 13140 oleh @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] [tes pembantu khusus] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js) # 13138 oleh @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] [tes debug ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/debug_test.js): gunting: # 13129 oleh @ code0100fun

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

• [x] [ #each-in tes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_in_test.js) # 13136 oleh @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 tes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_test.js) 🔒 oleh @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] [tes get ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/get_test.js) # 13173 , # 13264 oleh @ 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] [jika / kecuali pengujian] (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}} tes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/input_test.js) (: kunci: oleh @ 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 tes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/loc_test.js) # 13129 oleh @ 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] [tes log ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/log_test.js) # 13131 oleh @green -panah

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] [tes partial ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/p Partial_test.js ) # 13306 oleh @jheth dan @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] text_area tes # 13.215 oleh @kiwiupover

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 tes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/unbound_test.js) # 13137 oleh @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] [tes view ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/view_test.js) (: lock: by @bayu_joo

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 tes] (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] [tes yield ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/yield_test.js) (: lock: by @bayu_joo

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).

• Tes "Integrasi"
  
  
  
  • [x] [pengujian "pengikatan atribut"] (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] [tes "attrs_lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js) # 13203 oleh @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] [pengujian "integrasi pengikatan"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js) # 13210 oleh @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] [pengujian "blokir params"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) # 13189 oleh @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 tes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_element_id_test.js) # 13208 oleh @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] [pengujian pemanggilan komponen] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js) # 12890 oleh @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] [pengujian siklus hidup komponen] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js) (: lock: by @chancancode dan @ wycats)

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

• [x] [pengujian "escape"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/escape_integration_test.js) # 13143 oleh @ code0100fun + # 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] [pengujian "helper lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): gunting: # 13147 oleh @chadhietala

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

• [x] [ test] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js) (: lock: oleh @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] [pengujian "pencarian lokal"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): gunting:

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

• [x] [pengujian "pengikatan yang dapat diubah"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/mutable_binding_test.js): kunci:

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

• [x] [tes select ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/select_in_template_test.js): gunting: # 13144 oleh @HeroicEric

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

• [x] [pengujian "tanpa tag"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js): gunting: # 13146 oleh @ chadhietala

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] [pengujian "elemen kosong"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js): gunting: # 13187 oleh @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] [pengujian "willDestroyElement"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (: lock: oleh @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] [pengujian "dengan + tampilan"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js): gunting: # 13149 oleh @tokopedia

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>

• [] [Pengujian "Lihat pengelola node"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js ): gunting:: pertanyaan:

Implementasi ViewNodManager mungkin perlu bertahan lebih lama karena beberapa hal internal masih diimplementasikan sebagai tampilan di htmlbars, tetapi ini sepertinya tidak menguji sesuatu yang penting, jadi kita mungkin bisa: gunting: Itu? @rwjblue bisakah Anda mengonfirmasi?

• Tes "Sistem"
  
  
  
  • [x] ["tambahkan tampilan templated"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js): gunting: # 13148 oleh @chadhietala
  
  

This is likely legacy. Please do investigate!

• [x] [pengujian "bootstrap"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js): pertanyaan:: 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.

• [] [pengujian "penolong pencarian"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/lookup-helper_test.js): kunci: @mixonic

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

• [x] [pengujian "render env"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js): gunting:: kunci: 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?

Mungkin ada tes lain yang perlu di-porting juga. Jika Anda memperhatikan sesuatu yang saya lewatkan, silakan sebutkan di komentar.

Ulasan

Setelah Anda siap untuk mengirimkan PR Anda (jangan ragu untuk mengirimkan PR WIP!), Harap sebutkan masalah ini di deskripsi PR Anda, sehingga kami dapat memeriksanya.

Jangka waktu

Kami ingin mendapatkan sebanyak mungkin pengujian yang diporting secepat mungkin. Idealnya, kami ingin memiliki sebagian besar (jika tidak semua) pengujian yang ditransfer dalam satu atau dua minggu ke depan.

Terima kasih sebelumnya atas bantuan Anda! : hati:: hati_kuning:: hati_hijau:: hati_biru:: hati_ungu: