: रीसायकल:: रीसायकल:: रीसायकल: कृपया इस गीथूब मुद्दे को छापने से पहले पर्यावरण पर विचार करें। : रीसायकल:: रीसायकल:: रीसायकल:

बैकस्टोरी

@ वायट्स और मैं (और कई अन्य लोग जिन्होंने रास्ते में मदद की है) पिछले छह महीनों से प्रतिपादन इंजन के पुनर्निर्माण पर काम कर रहे हैं, जिसका नाम "ग्लिमर 2" है।

यह htmlbars के एक कांटे के रूप में शुरू हुआ था, लेकिन अब तक कोड की लगभग हर पंक्ति को फिर से लिखा गया है (कभी-कभी कई बार)। हमने पिछली पीढ़ी के रेंडरिंग पाइपलाइन (हैंडलबार, एचटीएमबीआर, मूल झिलमिलाहट

आप https://github.com/tildeio/glimmer पर कोडेज़ पा सकते हैं। यह टाइपस्क्रिप्ट में लिखा (पुनः) है, और मुझे लगता है कि यह बहुत अच्छा है। वैसे भी, EmberConf पर अधिक।

एकता

हालांकि अभी भी बहुत सारे काम हैं (ज्यादातर अनुकूलन) हम इंजन पर करना चाहते हैं, हमारा मानना ​​है कि हमने सभी मूल एम्बर उपयोग के मामलों को कवर करने के लिए पर्याप्त रूप से लागू किया है। इसलिए लगभग दो महीने पहले , हमने नए इंजन को एम्बर में एकीकृत करना शुरू कर दिया है। अब तक की हमारी प्रगति के लिए आप इस मेटा-इश्यू का अनुसरण कर सकते हैं।

हालांकि अभी नए इंजन का उपयोग वास्तविक ऐप्स में करना संभव नहीं है, फिर भी हम उम्मीद करते हैं कि यह काम जल्द ही पूरा हो जाएगा। उम्मीद यह है कि एक बार जब हमने कार्यान्वयन पूरा कर लिया है, तो यह HTMLBars माइग्रेशन के मूल हैंडलबार की तरह ही एप्स के लिए अपेक्षाकृत दर्द रहित, ड्रॉप-अप अपग्रेड होगा।

(यह ध्यान दिया जाना चाहिए कि फीचर फ्लैग को टॉगल करने की क्षमता संभवतः _before_ को लैंड कर देगी, सभी मौजूदा फीचर्स लागू हो जाएंगे, इसलिए यह गेट-गो से आपके ऐप के साथ सहज रूप से _not_ काम करेगा।)

Pls रुकावट भेजें

तो, आप सोच रहे होंगे, "मैं कैसे मदद कर सकता हूं?"

मैं खुश हूं कि आपने पूछा! : बूम:: चमक:: आतिशबाजी:: टाडा:

इस बिंदु पर, आपकी मदद करने के लिए उच्चतम मूल्य मौजूदा परीक्षणों को पोर्ट करने में मदद करता है (और इन पीआर की समीक्षा करने में मदद करता है)। आप देखते हैं, एम्बर में एक बहुत व्यापक परीक्षण सूट है जो "दृश्य परत" व्यवहार का परीक्षण करता है। समस्या यह है कि इनमें से बहुत सारे परीक्षण उन तरीकों से लिखे गए हैं जो मौजूदा कार्यान्वयन के लिए काफी युग्मित हैं या अन्यथा विरासत शब्दार्थ (जैसे {{view.foo}} ) का उपयोग करते हैं जो अब समर्थित नहीं हैं।

यह सुनिश्चित करने के लिए कि हमने कोई प्रतिगमन नहीं किया है, हम वर्तमान रेंडरिंग इंजन ("htmlbars") और ग्लिमर 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" चक्र ("प्रारंभिक रेंडर -> नो-ऑप रेंडरर -> अपडेट (एस) के माध्यम से म्यूटेशन (एस) -> रिसेटिंग थ्रू रिप्लेसमेंट" चक्र) के माध्यम से जाना, नीचे इस पर और अधिक)
   
   
   • हटाए गए (अनदेखे) परीक्षण (या परीक्षण जो उपरोक्त उल्लिखित अपडेट चक्र द्वारा कवर किए गए हैं) को हटाना (अनदेखा करना)
   
   
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 कोड को शॉर्ट-सर्किट कर देगा और कुछ भी नहीं करेगा।
• प्रतिस्थापन: फिर से, यदि मान स्ट्रिंग्स जैसे सरल आदिम मूल्य हैं, तो इससे कोई फर्क नहीं पड़ता है। लेकिन यदि मान ऑब्जेक्ट / सरणियाँ आदि हैं, तो इसका मतलब है कि उस ऑब्जेक्ट / सरणी को किसी अन्य नए ऑब्जेक्ट के साथ बदलना (जैसा कि इसके आंतरिक मूल्यों को बदलने के लिए विरोध किया गया है)। ( ऐरे उदाहरण , वस्तु उदाहरण )

डुप्लिकेट परीक्षणों से बचें

एक ही मामले की थोड़ी भिन्न भिन्नताओं का परीक्षण करने के लिए कुछ बार एक परीक्षण मामले की नकल करना आसान है (जैसे {{#if foo}} सच बनाम झूठ के साथ शुरू, या "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 में स्थित) को स्वचालित रूप से और कई साझा परीक्षण प्राप्त करती है।

"इनलाइन अगर / जब तक" परीक्षण इसे और आगे ले जाता है, 11 के खिलाफ परीक्षण के मामलों का एक ही सेट चल रहा है (!) विभिन्न आह्वान परिदृश्य।

बंटवारे की वास्तविक संरचना कुछ हद तक मुश्किल थी, पर पहुंचने में कुछ समय लगा और परिपक्व होने / सही होने में कुछ समय लगा, लेकिन अदायगी में बड़े पैमाने पर (मूल परिदृश्य अब {{#with}} और {{#each}} बीच साझा किए जाते हैं) भी)।

लिगेसी शब्दार्थ

बहुत सारे मौजूदा परीक्षणों में दृश्य, {{view.foo}} , {{#view}} , context , नियंत्रकों, आदि जैसे लीगेसी शब्दार्थों का उपयोग होता है। अधिकांश समय, यह विशुद्ध रूप से आकस्मिक है, और बस परीक्षण का परिणाम एक ऐसे समय में लिखा जा रहा है, जहां उन चीजों को करने का मुख्य तरीका था। उन मामलों में, आप आमतौर पर समस्याओं के बिना उन्हें नए दोहन (जो इसके बजाय घटकों का उपयोग करता है) में पोर्ट कर सकते हैं।

जब संदेह होता है, तो आप अपने पीआर के पहले पुनरावृत्ति में भी एक परीक्षण को अनपोर्ट कर सकते हैं और अपने प्रश्नों को एक लाइन टिप्पणी में पूछ सकते हैं।

attrs या attrs

हमने उन परीक्षणों में {{attrs.foo}} का उपयोग न करने का निर्णय लिया है जो घुंघराले घटकों (जो लगभग सभी के हैं) का उपयोग करता है और बल्कि केवल उसी नाम के साथ संपत्ति पर प्रतिबिंबित होने वाले अटार्स पर निर्भर होने का भरोसा करता है (अर्थात सिर्फ {{foo}} )। जब तक परीक्षण विशेष रूप से _about_ परीक्षण attrs.* (जो कि संभवतः सभी एक ही फ़ाइल में होने चाहिए), आपको सामान्यतः {{foo}} बजाय {{attrs.foo}} निरंतरता के लिए पसंद करना चाहिए। यदि आप की अवहेलना करने की आवश्यकता महसूस होती है, तो आप हमेशा innerFoo outerFoo जैसी चीजों को नाम दे सकते हैं।

Https://locks.svbtle.com/to-attrs-or-not-to-attrs @locks द्वारा भी देखें।

चेतावनियां

कभी-कभी आपके द्वारा जांचे गए परीक्षण शायद ग्लिमर 2 या HTMLBars पर भी काम न करें। (यदि यह या तो इंजन पर काम नहीं करता है, तो आपने शायद कुछ गलत किया है।)

इस मामले में जहां यह ग्लिमर 2 पर काम नहीं करता है, यह शायद इसलिए है क्योंकि हमने उस सुविधा को पूरी तरह से अभी तक लागू नहीं किया है। (उदाहरण के लिए, हमने बुनियादी घटकों के समर्थन को लागू किया है लेकिन इस बिंदु पर attributeBindings लागू नहीं किया है।)

इस मामले में, परीक्षण को नई शैली में पोर्ट करना अभी भी अच्छा है, ताकि सुविधा लागू होने पर हम इसे सक्षम कर सकें। अस्थायी रूप से ग्लिमर 2 के लिए एक परीक्षण को अक्षम करने के लिए, आप केवल @test उपसर्ग को विधि नाम में @htmlbars (जिसका अर्थ है "इसे HTMLBars- केवल में चला सकते हैं") में बदल सकते हैं। तुम भी अपने लगाकर द्वारा एक पूरे मॉड्यूल निष्क्रिय कर सकते हैं moduleFor के साथ नाम @htmlbars ।

कुछ दुर्लभ मामलों में, परीक्षण ग्लिमर 2 पर सही ढंग से काम करेगा लेकिन एचटीएमएलबार्स पर पारित नहीं होता है। आपको यह देखना चाहिए कि आपके द्वारा परीक्षण किए जा रहे शब्दार्थ सही हैं, लेकिन यह भी बहुत संभव है कि HTMLBars के वर्तमान कार्यान्वयन में एक बग है। (यह आमतौर पर तब होता है जब हम कुछ HTMLBars सुविधाओं का परीक्षण नई "मैट्रिक्स शैली" के साथ करते हैं, जहां मान कुछ नए मामलों में सही ढंग से अपडेट नहीं होते हैं।)

उस स्थिति में, आप इसी तरह एक व्यक्तिगत परीक्षण मामले या पूरे मॉड्यूल को @glimmer फ्लैग कर सकते हैं। चूंकि यह काफी दुर्लभ होने की उम्मीद है (और बग फिक्स की आवश्यकता हो सकती है), यह उपयोगी होगा यदि आप एक पंक्ति टिप्पणी में आपके द्वारा सामना की जाने वाली समस्याओं का एक संक्षिप्त विवरण शामिल कर सकते हैं।

उदाहरण

यहाँ कुछ महान उदाहरण हैं जहाँ हमारे समुदाय के सदस्यों ने मौजूदा परीक्षणों को पोर्ट करने में मदद की है:

• # 12920 इनलाइन {{if}} सहायक
• # 12927 {{#with}}
• # 13019 इनलाइन {{unless}}
• # 13093 (hash) सहायक

जैसा कि आप देख सकते हैं, पहले के पुनरावृत्तियों अधिक कठिन थे (हम अभी भी साझा किए गए परीक्षण मामलों की कहानी का पता लगा रहे थे), लेकिन बाद के प्रयास अपेक्षाकृत सीधे आगे थे। मार्ग प्रशस्त करने के लिए @GavinJoyce और @chadhietala को धन्यवाद!

तो मैं कहां से शुरू करूं?

यहां अच्छे शुरुआती बिंदुओं की सूची दी गई है। यदि आप इनमें से किसी एक पर काम करने के बारे में गंभीर हैं, तो आप शायद नीचे एक टिप्पणी छोड़ना चाहते हैं ताकि अन्य लोगों को उस पर काम न करने का पता चले। (यदि आप समय से बाहर भाग गए या बड़ी मुश्किल का सामना करना पड़ा, तो कृपया "लॉक रिलीज़ करें" और / या अपने WIP कार्य को आगे बढ़ाने के लिए वापस आएँ, इसलिए अन्य लोग इसे उठा सकते हैं!)

• [x] बेसिक कंटेंट रेंडरिंग टेस्ट # 13141 @chancancode द्वारा

मुझे नहीं पता कि यह पहले से मौजूद है या नहीं। कृपया इसे खोजने और पोर्ट करने का प्रयास करें। लेकिन अन्यथा, कृपया इसके लिए एक नई फ़ाइल बनाएं (हमने पहले से ही https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-stest.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) (: लॉक: achancancode और @ wycats)

हम इन परीक्षणों को बारीकी से देखना और आवश्यकताओं को समझना चाहेंगे। अभी के लिए इसे लॉक कर रहे हैं।

• [] [ compat परीक्षण] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat): कैंची:

हमने घोषणा की कि हम 2.6 से विरासत में जुड़ने वालों के लिए समर्थन समाप्त कर देंगे, इसलिए हमें ग्लिमर 2 में इन सुविधाओं का समर्थन करने की आवश्यकता नहीं होगी। कृपया परीक्षण और मास्टर पर सुविधाओं को हटाने के लिए पीआर खोलें। (यह शायद कोडबेस के अपेक्षाकृत गहरे ज्ञान की आवश्यकता होगी।)

• [x] [ glimmer-component परीक्षण] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component): कैंची: @ 13139 by @ लोरकन

यह फ़ोल्डर अप्रयुक्त है। कृपया इसे निकालने के लिए एक 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) (: ताला: द्वारा @ सेराबे)

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 ): कैंची:

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 @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 ): कैंची: @ 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 परीक्षण] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/get_test.js) # 13173, # 13,264 द्वारा @ 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: (लॉक: बाय @) गैविनजॉयस)

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 ) # 13306 @jheth और @chadietala द्वारा

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 परीक्षण # १३२१५ @ @wiiupover द्वारा

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: (ताला: द्वारा) @ चड्ढीताल)

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) (: लॉक: बाय @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_best.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] [ "ब्लॉक पैरामीटर" परीक्षण] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) # 13,189 @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_eleg_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) (: ताला: @chancancode और द्वारा @ wycats)

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

• [x] [ "भागने" परीक्षण] (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] ["सहायक खोज" परीक्षण # 13147 पर @ अचधीतला द्वारा

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 @padobrien)

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_nest.js): लॉक

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_tilplate_test.js): कैंची: # १३१४४ @HeroicEric द्वारा

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

• [x] [ "tagless विचारों" परीक्षण] (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" परीक्षण (: लॉक: @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 @ चड्ढीटाला द्वारा
  
  

This is likely legacy. Please do investigate!

• [x] ["बूटस्ट्रैप" परीक्षण] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js: प्रश्न: ताला: @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.

• [] ["लुकअप हेल्पर" टेस्ट्स

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/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 PRs सबमिट करने के लिए स्वतंत्र महसूस करें!), कृपया इस मुद्दे को अपने पीआर विवरण में देखें, ताकि हम उनकी समीक्षा कर सकें।

समय सीमा

हम जितनी जल्दी हो सके उतने टेस्टेड पोर्ट करवाना चाहते हैं। आदर्श रूप से, हम अगले सप्ताह या दो के भीतर सबसे अधिक परीक्षण (यदि सभी नहीं) करना चाहते हैं।

आपकी मदद के लिए अग्रिम धन्यवाद! : ह्रदय:: पीला_हार्ट:: हरा_हर्ट:: नीला_हार्ट:: बैंगनी_हार्ट: