: إعادة التدوير:: إعادة التدوير:: إعادة التدوير: يرجى مراعاة البيئة قبل طباعة مشكلة Github هذه. : إعادة التدوير:: إعادة التدوير:: إعادة التدوير:

الخلفية

كنا أنا و

لقد بدأت كشوكة من أشرطة htmlbars ولكن تمت إعادة كتابة كل سطر من التعليمات البرمجية تقريبًا (أحيانًا عدة مرات) حتى الآن. لقد قمنا بتقطير جميع الدروس المستفادة من بناء خطوط أنابيب التقديم من الجيل السابق (المقاود ، وأشرطة html ، ومشروع بصيص الأصلي ، وما إلى ذلك) ، مما أدى إلى بنية أكثر ملاءمة لحالات استخدام Ember في نفس الوقت ولكنها أيضًا أكثر مرونة وموضعًا جيدًا للتمديدات المستقبلية وحالات استخدام أخرى بخلاف Ember.

يمكنك العثور على كودز على https://github.com/tildeio/glimmer. تمت إعادة كتابته بلغة TypeScript ، وأعتقد أنه رائع جدًا. على أي حال ، المزيد عن ذلك في EmberConf .

التكامل

بينما لا يزال هناك الكثير من العمل (معظمه تحسينات) نود القيام به على المحرك ، نعتقد أننا قمنا بتنفيذ ما يكفي لتغطية جميع حالات استخدام Ember الأساسية. لذلك منذ حوالي شهرين ، بدأنا في دمج المحرك الجديد في Ember المناسب. يمكنك متابعة هذه المسألة الوصفية لتقدمنا حتى الآن.

على الرغم من عدم إمكانية استخدام المحرك الجديد في التطبيقات الحقيقية حتى الآن ، إلا أننا نتوقع اكتمال هذا العمل قريبًا نسبيًا. من المتوقع أنه بمجرد الانتهاء من التنفيذ ، ستكون ترقية سهلة نسبيًا للتطبيقات ، تمامًا مثل ترحيل Handbars الأصلي إلى HTMLBars.

(تجدر الإشارة إلى أن القدرة على تبديل علامة الميزة من المحتمل أن تصل _ قبل _ يتم تنفيذ جميع الميزات الحالية ، لذلك من المحتمل أن _لا تعمل بسلاسة مع تطبيقك من البداية.)

الرجاء إرسال هالب

لذا ، قد تتساءل ، "كيف يمكنني المساعدة؟"

أنا سعيد لأنك سألت! : boom:: Sparkles:: fireworks:: tada:

في هذه المرحلة ، أعلى قيمة يمكنك القيام بها للمساعدة هي المساعدة في نقل الاختبارات الحالية (والمساعدة في مراجعة هذه العلاقات العامة). كما ترى ، لدى Ember مجموعة اختبار واسعة جدًا تختبر سلوك "طبقة العرض". تكمن المشكلة في أن الكثير من هذه الاختبارات مكتوبة بطرق مرتبطة تمامًا بالتنفيذ الحالي أو تستخدم دلالات قديمة (مثل {{view.foo}} ) التي لم تعد مدعومة.

من أجل التأكد من أننا لم نتسبب في أي تراجع ، نود أن نكون قادرين على تشغيل مجموعة الاختبار الخاصة بنا بالكامل مقابل كل من محرك العرض الحالي ("htmlbars") و Glimmer 2.

لقد كتبنا أداة اختبار جديدة تسمح لنا بالقيام بذلك. سوف أتطرق إلى التفاصيل الفنية أدناه ، لكن الفكرة الأساسية هي أننا كتبنا حالات الاختبار الخاصة بنا ضد طبقة تجريد تلخص الاختلافات بين المحركين ، مما يسمح لنفس الكود في حالات الاختبار بالعمل ضد كلا التطبيقين.

على طول الطريق ، نقوم أيضًا "بتحديث" الاختبارات الحالية في العملية لعدم الاعتماد على الدلالات القديمة (ما لم تظهر أنها تختبر صراحةً تلك الدلالات ، وفي هذه الحالة سنتركها وشأنها). كما أن أداة الاختبار الجديدة لدينا تجعل إجراء اختبارات "نمط المصفوفة" أسهل بكثير وأكثر متعة. المزيد عن ذلك أدناه ، ولكن يوجد هنا مخطط معماري عالي المستوى:

والنتيجة النهائية هي أن الاختبارات أصبحت الآن أسهل في القراءة والتفسير ، كما قمنا بزيادة التغطية بشكل كبير. هذه نتيجة رائعة للجميع ، ولكن لا يزال لدينا الكثير من الاختبارات المتبقية ، ولا يمكننا أن نشعر بالثقة في شحن المحرك دون نقلهم جميعًا. ومع ذلك ، إذا كان بإمكان القليل منكم مساعدتنا في نقل ملف اختبار لكل منهم ، فسنكون في حالة جيدة جدًا بحلول هذا الوقت من الأسبوع المقبل!

كيف يعمل الحزام

الآلية الفعلية التي استخدمناها هي تقنية منخفضة للغاية. ربما سمعت عنها ، إنها تسمى روابط رمزية .

داخل مجلد الاختبار لحزمة ember-glimmer ، ستجد ملفًا يسمى abstract-test-case.js ، وهو أيضًا مرتبط بشكل رمزي بنفس الموقع داخل الحزمة ember-htmlbars . يحدد هذا الملف واجهات برمجة التطبيقات التي نستخدمها في كتابة حالات الاختبار. نظرًا لأن هذا الملف مشترك (مرتبط برمزًا) بين كلتا الحزمتين ، فإنه لا يحتوي على أي شيء محدد حول التطبيقين.

بدلاً من ذلك ، يتم تلخيص جميع الاختلافات عن طريق استيراد الملفات (مثل 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" ("العرض الأولي -> no-op rerender -> التحديث (التحديثات) عبر الطفرة (التحولات) -> إعادة التعيين عبر دورة الاستبدال ، المزيد حول هذا أدناه)
   
   
   • إزالة (تجاهل) الاختبارات المكررة (أو الاختبارات المشمولة ضمنيًا بواسطة دورة التحديث المذكورة أعلاه)
   
   
4. قم بربط الاختبار مرة أخرى بالحزمة ember-htmlbars ، ما لم يكن المجلد الأصلي بالفعل رابط رمزي في ember-htmlbars (مثل اختبار concat الذي عرضته أعلاه)
5. قم بإزالة الملف القديم (إلا إذا كان لا يزال يحتوي على بعض الاختبارات التي لا يمكن نقلها)
6. افتح طلب سحب
7. لتسهيل المراجعة ، أضف تعليقًا سطرًا لكل حالة اختبار قمت بإزالتها ، موضحًا الأساس المنطقي (على سبيل المثال ، تم نقله إلى/ يتم تغطيتها الآن عبر/ كان تكرارًا لـ/ ...). يمكنك أيضًا عدم التردد في إضافة تعليقات / أسئلة على الاختبارات التي لست متأكدًا منها.

كيف تكتب اختبارات جيدة

فيما يلي بعض النصائح / القواعد العامة التي يمكنك اتباعها لتحسين حالات الاختبار.

دورة "INUR"

نود أن يمر كل اختبار بدورة "INUR":

1. تصيير أولي

قم بتقديم النموذج الذي تريد اختباره ، مع القيم الأولية التي تختارها ( this.render(..., { ... }) ) وأكد أن النتيجة هي ما تتوقعه. ( مثال )

1. إعادة تصيير بدون عملية

استدع this.runTask(() => this.rerender()); بدون أي تغييرات على القيم ، ثم أكد أن النتيجة تبقى كما هي. ( مثال )

1. التحديث (التحديثات) عبر الطفرة (التحولات)

قم بإجراء بعض التحديثات على القيم التي تستخدمها في القوالب. ( مثال )

يجب أن تحاول:

• قسّم التحديثات إلى أجزاء متعددة (مثل تأكيد this.runTask + متعدد) إذا كان ذلك منطقيًا. يؤدي هذا إلى زيادة فرص اصطياد أخطاء "الضرب" حيث يؤدي تحديث _ بعض القيم إلى "إزالة" جزء آخر غير ذي صلة من القالب أو يتسبب في تأثيرات أخرى غير مرغوب فيها.
• استخدم "الطفرات الداخلية" إذا كان ذلك منطقيًا. عندما تكون القيمة مجرد سلسلة أو قيمة أولية أخرى ، فإن هذا لا يهم ، ولكن عندما تتعامل مع كائن أو مصفوفة ، فهذا يعني تحديث القيم "داخل" الكائن / المصفوفة مع الاحتفاظ بالعنصر / المصفوفة نفسه. ( مثال مصفوفة ، مثال كائن )
• جرب أشكالًا مختلفة من "الطفرات الداخلية" إذا كان ذلك منطقيًا. عندما يكون هناك أكثر من طريقة للقيام بذلك (على سبيل المثال pushObject مقابل إزالة عنصر ، وما إلى ذلك) ، فمن الجيد عادةً تجربة أكثر من طريقة واحدة. ( مثال )
  
  
  
  1. إعادة عن طريق الاستبدال
  
  

إعادة التعيين إلى حالة البداية الأصلية عن طريق استبدال جميع المتغيرات.

• إعادة التعيين: يساعد هذا في اكتشاف الأخطاء حيث نقوم بتخزين القيمة الأصلية لعقدة النص مؤقتًا وننسى تحديث ذاكرة التخزين المؤقت على طول الطريق. في هذه الحالة ، عندما تقوم بتغييره إلى أي شيء آخر غير القيمة الأصلية ، فإنه يعمل بشكل جيد ؛ ولكن عندما تعيده إلى القيمة الأصلية ، فإنه سيقصر رمز DOM ولن يفعل شيئًا.
• الاستبدال: مرة أخرى ، إذا كانت القيم عبارة عن قيم أولية بسيطة مثل السلاسل ، فلن يحدث فرقًا. ولكن إذا كانت القيم عبارة عن كائنات / مصفوفات ، وما إلى ذلك ، فهذا يعني استبدال هذا الكائن / المصفوفة بكائن جديد آخر (بدلاً من تغيير قيمها الداخلية). ( مثال مصفوفة ، مثال كائن )

تجنب تكرار الاختبارات

من السهل نسخ حالة اختبار عدة مرات لاختبار أشكال مختلفة قليلاً من الشيء نفسه (على سبيل المثال ، {{#if foo}} بدءًا من true مقابل false ، أو الفرق بين "POJO" مقابل Ember.Object ) ، وقد فعلنا ذلك كثيرًا في الاختبارات الحالية.

في بعض الأحيان يكون هذا أفضل ما يمكنك القيام به ، ولكن هناك الكثير من المشاكل مع هذا. أولاً ينتج عددًا كبيرًا من الاختبارات فعليًا في الملف ، مما يجعل من الصعب العثور على الأشياء. أيضًا ، عندما يحتاج شخص ما إلى إضافة اختبار جديد ، فعادة ما يختار بشكل عشوائي أحد المتغيرات القليلة ، ويحمل التفاصيل / الأخطاء التي لا تعني الكثير للسيناريو الجديد. عندما نصلح الأخطاء في إحدى النسخ ، من المحتمل أن ننسى الباقي.

عادة ، هناك طرق لتجنب الازدواجية. على سبيل المثال ، في حالة اختبار حالة البدء المختلفة ( {{#if foo}} مقابل 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 ) ويحصل تلقائيًا على العديد من الاختبارات المشتركة.

تأخذ اختبارات "inline if / ما لم" تأخذ هذا الأمر إلى أبعد من ذلك ، حيث تقوم بتشغيل نفس مجموعة حالات الاختبار مقابل 11 (!) سيناريوهات استدعاء مختلفة.

كان من الصعب إلى حد ما الوصول إلى الهيكل الفعلي للمشاركة ، واستغرق بعض الوقت حتى تنضج / تصبح صحيحة ، ولكن المردود كان هائلاً (السيناريوهات الأساسية مشتركة الآن بين {{#with}} و {{#each}} كذلك).

دلالات الإرث

تستخدم الكثير من الاختبارات الحالية دلالات قديمة مثل المشاهدات ، {{view.foo}} ، {{#view}} ، context ، وحدات التحكم ، إلخ. في معظم الأوقات ، هذا عرضي تمامًا ، وفقط نتيجة الاختبار الذي تمت كتابته في وقت كانت فيه تلك الأوليات هي الطريقة الرئيسية للقيام بالأشياء. في هذه الحالات ، يمكنك عادةً نقلها إلى الأداة الجديدة (التي تستخدم المكونات بدلاً من ذلك) دون مشاكل.

عندما تكون في شك ، يمكنك أيضًا إجراء اختبار لم يتم الإبلاغ عنه في التكرار الأول للعلاقات العامة الخاصة بك وطرح أسئلتك في تعليق سطر.

إلى attrs أو لا إلى attrs

قررنا عدم استخدام {{attrs.foo}} في الاختبارات التي تستخدم مكونات مجعدة (وهي كلها تقريبًا) والاعتماد فقط على Attrs التي تنعكس على الخاصية التي تحمل الاسم نفسه (على سبيل المثال {{foo}} ). ما لم يكن الاختبار على وجه التحديد _about_ اختبار attrs.* (من المحتمل أن تكون جميعها في نفس الملف) ، يجب أن تفضل بشكل عام {{foo}} بدلاً من {{attrs.foo}} للتوافق. يمكنك دائمًا تسمية أشياء مثل innerFoo مقابل outerFoo إذا كنت تشعر بالحاجة إلى توضيح.

راجع أيضًا https://locks.svbtle.com/to-attrs-or-not-to-attrs بواسطةlocks.

تحفظات

في بعض الأحيان ، قد لا تعمل الاختبارات التي قمت بنقلها على Glimmer 2 أو HTMLBars. (إذا لم يعمل على أي محرك ، فربما تكون قد فعلت شيئًا خاطئًا).

في حالة عدم عملها على Glimmer 2 ، فمن المحتمل أن يكون ذلك بسبب أننا لم ننفذ هذه الميزة بالكامل حتى الآن. (على سبيل المثال ، قمنا بتنفيذ دعم المكونات الأساسية ولكننا لم ننفذ attributeBindings في هذه المرحلة.)

في هذه الحالة ، لا يزال من الجيد نقل الاختبار إلى النمط الجديد ، بحيث يمكننا ببساطة تمكينه عند تنفيذ الميزة. لتعطيل اختبار مؤقتًا لـ Glimmer 2 ، يمكنك ببساطة استبدال البادئة @test في اسم الطريقة بـ @htmlbars (مما يعني "تشغيل هذا في HTMLBars فقط"). يمكنك أيضًا تعطيل وحدة كاملة عن طريق إضافة بادئة اسمها moduleFor بـ @htmlbars .

في بعض الحالات النادرة ، سيعمل الاختبار بشكل صحيح على Glimmer 2 لكنه لا يمر عبر HTMLBars. يجب عليك التحقق مرة أخرى من صحة الدلالات التي تختبرها ، ولكن من المحتمل أيضًا وجود خطأ في التنفيذ الحالي لـ HTMLBars. (يحدث هذا عادة عندما نختبر بعض ميزات أشرطة HTML باستخدام "نمط المصفوفة" الجديد ، حيث لا يتم تحديث القيم بشكل صحيح في بعض حالات الحواف.)

في هذه الحالة ، يمكنك بالمثل وضع علامة على حالة اختبار فردية أو وحدة كاملة على أنها @glimmer . نظرًا لأنه من المتوقع أن يكون هذا نادرًا جدًا (وقد يتطلب إصلاحًا للأخطاء) ، فسيكون من المفيد تضمين وصف موجز للمشكلات التي تواجهها في سطر تعليق.

أمثلة

فيما يلي بعض الأمثلة الرائعة حيث ساعد أعضاء مجتمعنا في نقل الاختبارات الحالية:

• # 12920 مساعد مضمن {{if}}
• # 12927 {{#with}}
• # 13019 مضمن {{unless}}
• # 13093 (hash) المساعد

كما ترون ، كانت التكرارات السابقة أكثر صعوبة (كنا لا نزال نكتشف قصة حالات الاختبار المشتركة) ، لكن المحاولات الأخيرة كانت مباشرة نسبيًا. شكرًا لك GavinJoyce و chadhietala على تمهيد الطريق!

إذن ... من أين أبدأ؟

فيما يلي قائمة بنقاط البداية الجيدة. إذا كنت جادًا في العمل على أحد هذه الأشياء ، فربما تريد ترك تعليق أدناه حتى يعرف الآخرون عدم العمل على ذلك. (إذا نفد الوقت أو واجهت صعوبة كبيرة ، فالرجاء العودة إلى "تحرير القفل" و / أو دفع عملك قيد التقدم ، حتى يتمكن الآخرون من استلامه!)

• [x] اختبارات تقديم المحتوى الأساسي # 13141 بواسطةchancancode

لا أعرف ما إذا كان هذا موجودًا بالفعل. يرجى محاولة العثور عليه والميناء إذا كان كذلك. ولكن بخلاف ذلك ، يرجى إنشاء ملف جديد له (لقد بدأنا بالفعل شيئًا ما في https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js) . الفكرة هي أننا نريد اختبار "ما يحدث إذا أدخلت شيئًا غريبًا في DOM" ، مثل {{foo}} ، حيث foo هو undefined ، null ، و object ، إلخ. هذا هو الهدف الرئيسي لاختبار "Matrix Style" ، لذلك قد ترغب في دراسة كيفية عمل أداة الاختبار واستخلاص الأفكار من الاختبارات الشرطية.

يجب أن يمتص هذا أيضًا 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) (: قفل: بواسطة chancancode و @ wycats)

نود أن نلقي نظرة فاحصة على هذه الاختبارات وفهم المتطلبات. قفله الآن.

• [] [اختبارات compat ] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat): المقص:

أعلنا أننا سننهي دعم الوظائف الإضافية القديمة بحلول 2.6 ، لذلك لن نحتاج إلى دعم هذه الميزات في Glimmer 2. يرجى فتح PRs لإزالة الاختبارات والميزات الموجودة على Master. (قد يتطلب هذا معرفة عميقة نسبيًا بقاعدة الشفرة).

• [x] [اختبارات glimmer-component ] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component): المقص: # 13139 بواسطة @ لوركان

هذا المجلد غير مستخدم. يرجى إرسال PR لإزالته.

• المساعدون (أعتقد أنه يجب علينا نقلهم إلى tests/integration/helpers )
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js): قفل :
  
  

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 test] (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 helper] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/component_test.js) # 13140 بواسطة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 بواسطة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 بواسطة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) 🔒 بواسطة 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 testing ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/get_test.js) # 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] [إذا / ما لم تكن الاختبارات] (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 @ جافين جويس)

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 بواسطة @ 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 بواسطة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] اختبارات text_area # 13215 بواسطة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 ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/unbound_test.js) # 13137 بواسطة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 بواسطة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 بواسطة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 بواسطة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 بواسطة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 بواسطة @ 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: bycancancode و @ 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 بواسطة @ 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] [اختبار "helper lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): المقص: # 13147 بواسطة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: bypaddyobrien)

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): المقص:

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): قفل:

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

• [x] [ select test] (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): المقص: # 13146 بواسطة @ شاديتالا

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] [اختبار "عنصر باطل"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js): المقص: # 13187 بواسطة 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) (: قفل: بواسطة @ 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] [اختبارات "مع + عرض"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js): المقص: # 13149 بواسطة تضمين التغريدة

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 ): مقص:: سؤال:

ربما يحتاج تطبيق ViewNodManager إلى البقاء لفترة أطول قليلاً لأن بعض الأشياء الداخلية لا تزال مطبقة كطرق عرض في أشرطة htmlbars ، ولكن هذا لا يبدو أنه يختبر أي شيء مهم ، لذا يمكننا على الأرجح: المقص: ذلك؟ rwjblue هل يمكنك التأكيد؟

• اختبارات "النظام"
  
  
  
  • [x] ["إلحاق عرض نموذجي"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js): المقص: # 13148 بواسطة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): السؤال:: 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.

• [] [اختبارات "lookup helper"] (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] [اختبارات "عرض env"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js): المقص:: القفل: https : //github.com/emberjs/ember.js/pull/13399mixonic

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?

من المحتمل أن تكون هناك اختبارات أخرى يجب إجراؤها أيضًا. إذا لاحظت أي شيء فاتني ، فيرجى ذكره في التعليقات.

المراجعات

بمجرد أن تكون مستعدًا لإرسال العلاقات العامة الخاصة بك (يرجى عدم التردد في تقديم PRs PR!) ، يرجى الإشارة إلى هذه المشكلة في وصف العلاقات العامة الخاصة بك ، حتى نتمكن من مراجعتها.

إطار زمني

نريد إجراء أكبر عدد من الاختبارات في أسرع وقت ممكن. من الناحية المثالية ، نود إجراء معظم الاختبارات (إن لم يكن كلها) خلال الأسبوع أو الأسبوعين المقبلين.

شكرا لكم مقدما على مساعدتكم! : heart:: yellow_heart:: green_heart:: blue_heart: purple_heart: