: recycle : : recycle : : recycle : 이 Github 문제를 인쇄하기 전에 환경을 고려하십시오. : recycle : : recycle : : recycle :

배경 이야기

@wycats 와 I (그리고 그 과정에서 도움을 준 많은 사람들)은 지난 6 개월 동안 코드 명 "Glimmer 2"라는 렌더링 엔진의 재 구축 작업을 해왔습니다.

그것은 htmlbar 의 포크로 시작되었지만 거의 모든 코드 줄이 지금까지 (때로는 여러 번) 다시 작성되었습니다. 우리는 이전 세대의 렌더링 파이프 라인 (핸들 바, htmlbars, 원래의 glimmer

https://github.com/tildeio/glimmer에서 codez를 찾을 수 있습니다. TypeScript로 (재) 작성되었으며 꽤 멋지다고 생각합니다. 어쨌든 EmberConf 에서 더 자세히

통합

엔진에서하고 싶은 많은 작업 (대부분 최적화)이 아직 많이 남아 있지만 모든 기본 Ember 사용 사례를 포함 할 수있을만큼 충분히 구현했다고 생각합니다. 그래서 약 두 달 전에 우리는 새로운 엔진을 Ember로 통합하기 시작했습니다. 지금까지의 진행 상황을 위해이 메타 문제 를 따를 수 있습니다.

아직 실제 앱에서 새 엔진을 사용할 수는 없지만 작업이 비교적 빨리 완료 될 것으로 예상됩니다. 구현이 완료되면 원래 Handlebars에서 HTMLBars로 마이그레이션하는 것처럼 상대적으로 쉽게 앱을위한 드롭 인 업그레이드가 될 것입니다.

(기능 플래그를 전환하는 기능은 기존 기능이 모두 구현되기 _ 전에 _ 시작될 것이므로, 처음부터 앱에서 원활하게 작동하지 _ 않을 _ 것입니다.)

Pls는 중단을 보냅니다

따라서 "어떻게 도와 드릴까요?"라고 궁금해하실 수 있습니다.

물어봐서 기뻐요! : 붐 : : 스파클 스 : : 불꽃 놀이 : : 타다 :

이 시점에서 도움이 될 수있는 가장 큰 가치는 기존 테스트를 이식하고 이러한 PR을 검토하는 데 도움이되는 것입니다. Ember에는 "뷰 레이어"동작을 테스트하는 매우 광범위한 테스트 스위트가 있습니다. 문제는 이러한 테스트의 대부분이 기존 구현과 상당히 결합 된 방식으로 작성되거나 더 이상 지원되지 않는 레거시 의미 체계 (예 : {{view.foo}} )를 사용한다는 것입니다.

회귀가 발생하지 않았는지 확인하기 위해 현재 렌더링 엔진 ( "htmlbars")과 Glimmer 2 모두에 대해 전체 테스트 스위트를 실행할 수 있기를 원합니다.

우리는 그렇게 할 수있는 새로운 테스트 도구를 작성했습니다. 아래에서 기술적 인 세부 사항을 살펴 보 겠지만 기본 아이디어는 두 엔진 간의 차이점을 캡슐화하는 추상화 계층에 대해 테스트 케이스를 작성하여 테스트 케이스의 동일한 코드가 두 구현 모두에 대해 실행될 수 있도록한다는 것입니다.

그 과정에서 레거시 시맨틱에 의존하지 않도록 프로세스의 기존 테스트를 "현대화"하고 있습니다 (이 시맨틱을 명시 적으로 테스트하는 것처럼 보이지 않는 한,이 경우에는 그대로 둡니다). 우리의 새로운 테스트 장치는 또한 "매트릭스 스타일"테스트를 훨씬 더 쉽고 즐겁게 만들어줍니다. 아래에서 더 자세히 설명하지만 여기에 상위 수준 아키텍처 다이어그램이 있습니다.

결과적으로 테스트를 훨씬 쉽게 읽고 추론 할 수 있으며 적용 범위도 크게 증가했습니다. 이것은 모두에게 훌륭한 결과이지만 아직 더 많은 테스트가 남아 있으며 모든 테스트가 포팅되지 않은 상태에서 엔진 출하에 대한 확신을 가질 수 없습니다. 그러나 여러분 중 몇 분이 각각 테스트 파일을 이식하는 데 도움을 주시면 다음 주 이맘때까지 좋은 상태가 될 것입니다!

하네스 작동 원리

우리가 사용한 실제 메커니즘은 매우 낮은 기술입니다. 들어 보셨을 것입니다.이를 심볼릭 링크 라고

ember-glimmer 패키지의 테스트 폴더 안에 abstract-test-case.js 라는 파일이 있습니다.이 파일은 ember-htmlbars 패키지 내의 동일한 위치에 심볼릭 링크되어 있습니다. 이 파일은 테스트 케이스 작성에 사용되는 API를 정의합니다. 이 파일은 두 패키지간에 공유 (symlinked)되기 때문에 두 구현에 대한 구체적인 내용은 포함하지 않습니다.

대신 각 패키지에서 제공하는 파일 (예 : 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 패키지로 다시 심볼릭합니다 (위에서 보여준 concat 테스트와 유사 함).
5. 이전 파일을 제거합니다 (이전 할 수없는 일부 테스트가 여전히 포함되어 있지 않은 경우).
6. 풀 리퀘스트 열기
7. 쉽게 검토 할 수 있도록 제거한 각 테스트 케이스에 대한 설명을 추가하여 근거를 설명합니다 (예 :/ 이제 다음을 통해 다룹니다./ 중복/ ...). 확실하지 않은 테스트에 대한 의견 / 질문을 자유롭게 추가 할 수도 있습니다.

좋은 테스트를 작성하는 방법

다음은 테스트 사례를 개선하기 위해 따를 수있는 몇 가지 일반적인 팁 / 규칙입니다.

"INUR"주기

각 테스트가 "INUR"주기를 거치기를 바랍니다.

1. 초기 렌더링

선택한 초기 값 ( this.render(..., { ... }) )으로 테스트 할 템플릿을 렌더링하고 결과가 예상 한대로임을 주장합니다. ( 예 )

1. 작동하지 않는 다시 렌더링

값을 변경하지 않고 this.runTask(() => this.rerender()); 를 호출 한 다음 결과가 동일하다고 주장합니다. ( 예 )

1. 돌연변이를 통한 업데이트

템플릿에서 사용하는 값을 업데이트합니다. ( 예 )

다음을 시도해야합니다.

• 의미가있는 경우 업데이트를 여러 청크로 분할합니다 (즉, 여러 this.runTask + 어설 션). 이렇게하면 _some_ 값을 업데이트하면 템플릿의 다른 관련되지 않은 부분이 "날아가거나"다른 바람직하지 않은 효과가 발생하는 "클로버 링"버그를 잡을 가능성이 높아집니다.
• 말이되는 경우 "내부 돌연변이"를 사용하십시오. 값이 문자열이나 기타 기본 값일 때는 중요하지 않지만 객체 나 배열을 다룰 때는 객체 / 배열을 유지하면서 객체 / 배열의 "내부"값을 업데이트해야합니다. 같은. ( 배열 예 , 객체 예 )
• 의미가 있다면 다른 형태의 "내부 돌연변이"를 시도해보십시오. 이 작업을 수행하는 방법이 여러 가지 (예 : pushObject vs 항목 제거 등)가있는 경우 일반적으로 둘 이상의 방법을 시도하는 것이 좋습니다. ( 예 )
  
  
  
  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 )를 정의하고 자동으로 많은 공유 테스트를 가져옵니다.

"인라인 if / unless"테스트 는 11 (!) 개의 서로 다른 호출 시나리오에 대해 동일한 테스트 케이스 세트를 실행하여이 작업을 더욱 확장합니다.

공유의 실제 구조는 도달하기가 다소 어려웠고 성숙하고 제대로되는 데 시간이 좀 걸렸지 만 그에 따른 결과는 엄청났습니다 (기본 시나리오는 이제 {{#with}} 와 {{#each}} 사이에서 공유됩니다. 게다가).

레거시 의미론

기존의 많은 테스트는 뷰, {{view.foo}} , {{#view}} , context , 컨트롤러 등과 같은 레거시 의미 체계를 사용합니다. 대부분의 경우 이것은 순전히 부수적이며 그 원시적 요소가 일을 수행하는 주요 방법이었던 시대에 작성된 테스트의 결과. 이러한 경우 일반적으로 문제없이 새 하네스 (대신 구성 요소를 사용)로 이식 할 수 있습니다.

의심스러운 경우 PR의 첫 번째 반복에서 이식되지 않은 테스트를 수행하고 줄 주석으로 질문 할 수도 있습니다.

attrs 또는 attrs

우리는 둥근 구성 요소 (거의 모든 구성 요소)를 사용하는 테스트에서 {{attrs.foo}} 를 사용하지 않고 동일한 이름 (즉, {{foo}} 가진 속성에 반영되는 속성에만 의존하기로 결정했습니다. attrs.* (모두 같은 파일에 있어야 함)가 아니면 일반적으로 일관성을 위해 {{attrs.foo}} 보다는 {{foo}} 선호해야합니다. 명확화 할 필요가 있다고 생각되면 innerFoo 대 outerFoo 와 같은 이름을 언제든지 지정할 수 있습니다.

@locks의 https://locks.svbtle.com/to-attrs-or-not-to-attrs도 참조하십시오.

주의 사항

포팅 한 테스트가 Glimmer 2 또는 HTMLBar에서 작동하지 않는 경우가 있습니다. (두 엔진 모두에서 작동하지 않으면 뭔가 잘못한 것입니다.)

Glimmer 2에서 작동하지 않는 경우 해당 기능을 아직 완전히 구현하지 않았기 때문일 수 있습니다. (예를 들어 기본 구성 요소 지원을 구현했지만 현재 attributeBindings 는 구현하지 않았습니다.)

이 경우에도 테스트를 새로운 스타일로 이식하는 것이 좋습니다. 그래야 기능이 구현 될 때 간단히 활성화 할 수 있습니다. Glimmer 2에 대한 테스트를 일시적으로 비활성화하려면 메서드 이름의 @test 접두사를 @htmlbars 로 바꾸면됩니다 ( "HTMLBars에서만 실행"을 의미 함). 당신은 또한 접두사에 의해 전체 모듈을 해제 할 수 있습니다 moduleFor 에 이름을 @htmlbars .

드문 경우지만 테스트는 Glimmer 2에서 제대로 작동하지만 HTMLBar에서는 통과하지 못합니다. 테스트중인 의미가 올바른지 다시 확인해야하지만 현재 HTMLBars 구현에 단순히 버그가있을 수도 있습니다. (이것은 일반적으로 새로운 "매트릭스 스타일"을 사용하여 일부 HTMLBars 기능을 테스트 할 때 발생하며, 일부 경우에는 값이 올바르게 업데이트되지 않습니다.)

이 경우 유사하게 개별 테스트 케이스 또는 전체 모듈을 @glimmer 로 플래그 지정할 수 있습니다. 이것은 매우 드물게 예상되기 때문에 (버그 수정이 필요할 수 있음), 줄 주석에 발생한 문제에 대한 간략한 설명을 포함 할 수 있으면 도움이 될 것입니다.

예

다음은 커뮤니티 구성원이 기존 테스트를 이식하는 데 도움을 준 훌륭한 예입니다.

• # 12920 인라인 {{if}} 도우미
• # 12927 {{#with}}
• # 13019 인라인 {{unless}}
• # 13093 (hash) 도우미

보시다시피 초기 반복은 더 어려웠지만 (우리는 여전히 공유 된 테스트 케이스 스토리를 파악하고있었습니다) 후자의 시도는 비교적 간단했습니다. 길을 열어 준 @GavinJoyce 와 @chadhietala 에게 감사드립니다!

그래서 .. 어디서부터 시작해야하나요?

다음은 좋은 출발점 목록입니다. 이 중 하나에 대해 진지하게 작업하는 경우 다른 사람들이 작업하지 않는 것을 알 수 있도록 아래에 의견을 남기고 싶을 것입니다. (시간이 부족하거나 큰 어려움을 겪은 경우 "잠금 해제"로 돌아 오거나 WIP 작업을 밀어 다른 사람이 선택할 수 있도록하십시오!)

• [x] @chancancode의 기본 콘텐츠 렌더링 테스트

이것이 이미 존재하는지 모르겠습니다. 그것이 있다면 그것을 찾아서 포트하십시오. 그러나 그렇지 않으면 새 파일을 만드십시오 (이미 https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js에서 시작했습니다) . 아이디어는 "DOM에 이상한 것을 넣으면 어떻게되는지"테스트하는 것입니다. 예 : {{foo}} , 여기서 foo 는 undefined , null , 및 객체 등. 이것은 "매트릭스 스타일"테스트의 주요 대상이므로 테스트 도구가 작동하는 방식을 연구하고 조건부 테스트에서 아이디어를 도출하는 것이 좋습니다.

또한 https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js도 흡수해야합니다.

• [x] [ attr_nodes 테스트] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/attr_nodes) (: lock : @chancancode 및 @ wycats)

이러한 테스트를 자세히 살펴보고 요구 사항을 이해하고 싶습니다. 지금은 잠급니다.

• [] [ compat 테스트] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat) : 가위 :

2.6까지 레거시 애드온에 대한 지원을 종료한다고 발표 했으므로 Glimmer 2에서 이러한 기능을 지원할 필요가 없습니다. PR을 열어 마스터의 테스트 및 기능을 제거하십시오. (이것은 아마도 코드베이스에 대한 상대적으로 깊은 지식이 필요할 것입니다.)

• [x] [ glimmer-component 테스트] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component) : scissors : # 13139 by @ Lorcan

이 폴더는 사용되지 않습니다. 제거하려면 PR을 보내십시오.

• 도우미 ( tests/integration/helpers 로 옮겨야한다고 생각합니다)
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js) : lock :
  
  

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

• [x] [ closure component ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/closure_component_test.js) (: lock : by @ 세라 베)

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

• [x] [ collection 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/collection_test.js) : 가위 : # 13161 작성자 @HeroicEric

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

• [x] [ #component helper] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/component_test.js) # 13140 by @GavinJoyce

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

• [x] [custom helper tests] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js) # 13138 by @zackthehuman

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

• [x] [ debug 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/debug_test.js) : scissors : # 13129 작성자 @ code0100fun

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

• [x] [ #each-in 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_in_test.js) # 13136 by @mmun

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

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

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

• [x] [ #each 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_test.js) 🔒 @Joelkang 제공

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

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

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

• [x] [ get 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/get_test.js) # 13173 , # 13264 작성자 @ ro0gr

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

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

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

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

• [] [ {{input}} 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/input_test.js) (: lock : by @ 개빈 조이스)

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

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

• [x] [ loc 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/loc_test.js) # 13129 by @ code0100fun

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

• [x] [ log 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/log_test.js) # 13131 by @green -화살

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

• [x] [ partial 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/partial_test.js) # 13199 , # 13306 작성자 @jheth 및 @chadhietala

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

• [x] text_area 테스트 # 13215 by @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 by @chadhietala

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

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

• [x] [ view 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/view_test.js) (: lock : by @chadhietala)

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

• [x] [ with 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/with_test.js)

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

• [x] [ yield 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/yield_test.js) (: lock : by @kiwiupover)

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

• "통합"테스트
  
  
  
  • [x] [ "속성 바인딩"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attribute_bindings_test.js) 🔒 @chadhietala #
  
  

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

• [x] [ "attrs_lookup"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js) # 13203 by @Joelkang

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

• [x] [ "바인딩 통합"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js) # 13210 by @Joelkang

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

• [x] [ "block params"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) # 13189 by @Joelkang

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

• [x] [ elementId 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_element_id_test.js) # 13208 by @jheth

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

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

• [x] [컴포넌트 호출 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js) # 12890 by @Serabe

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

• [x] [구성 요소 수명주기 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js) (: lock : @chancancode 및 @ wycats)

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

• [x] [ "escape"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/escape_integration_test.js) # 13143 by @ 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] [ "도우미 조회"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js) : 가위 : # 13147 by @chadhietala

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

• [x] [ test] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js) (: lock : by @paddyobrien)

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

• [x] [ "로컬 조회"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js) : 가위 :

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

• [x] [ "변경 가능한 바인딩"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/mutable_binding_test.js) : lock :

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

• [x] [ select 테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/select_in_template_test.js) : 가위 : # 13144 작성자 @HeroicEric

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

• [x] [ "태그없는 뷰"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js) : scissors : # 13146 by @ 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] [ "void element"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js) : 가위 : # 13187 by @MatrixZ

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

• [x] [ "willDestroyElement"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (: lock : @krisselden 작성)

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

• [x] [ "with + view"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js) : scissors : # 13149 by 뿡 빵뀨

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 의 구현은 아마도 약간 더 오래 머무를 필요가있을 것입니다. 왜냐하면 내부적 인 것들은 여전히 ​​htmlbar에서 뷰로 구현되기 때문입니다. 그러나 이것은 중요한 것을 테스트하는 것 같지 않습니다. 그래서 우리는 아마도 : scissors : 그것? @rwjblue 확인할 수 있습니까?

• "시스템"테스트
  
  
  
  • [x] [ "템플릿보기 추가"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js) : 가위 : # 13148 by @chadhietala
  
  

This is likely legacy. Please do investigate!

• [x] [ "부트 스트랩"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js) : question : : lock : @krisselden

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

• [] [ "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] [ "렌더 환경"테스트] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js) : scissors : : lock : https : //github.com/emberjs/ember.js/pull/13399 @mixonic

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

포팅해야 할 다른 테스트도있을 것입니다. 내가 놓친 것을 발견했다면 댓글에 언급하십시오.

리뷰

PR을 제출할 준비가 되었으면 (WIP PR을 제출해도됩니다!) PR 설명에서이 문제를 참조하여 검토 할 수 있도록하십시오.

기간

가능한 한 빨리 많은 테스트를 이식하려고합니다. 이상적으로는 다음 주 또는 2 주 내에 대부분의 (모두는 아니지만) 테스트를 이식하고 싶습니다.

당신의 도움에 미리 감사드립니다! : heart : : yellow_heart : : green_heart : : blue_heart : : purple_heart :