: recycle:: recycle:: recycle: Пожалуйста, рассмотрите среду, прежде чем печатать эту проблему Github. : recycle:: recycle:: recycle:

Предыстория

@wycats и я (и многие другие люди, которые помогали на этом пути) работали над перестройкой движка рендеринга под кодовым названием "Glimmer 2".

Он начинался как форк htmlbars, но к настоящему времени почти каждая строка кода была переписана (иногда по несколько раз). Мы извлекли все уроки из создания конвейеров рендеринга предыдущего поколения (handlebars, htmlbars, исходный проект glimmer и т. Д.), В результате чего была получена архитектура, которая одновременно больше подходит для сценариев использования Ember, но также является более гибкой и удобной для будущих расширений. и другие варианты использования, отличные от Ember.

Вы можете найти код по адресу https://github.com/tildeio/glimmer. Он (пере) написан на TypeScript, и я думаю, что это довольно круто. Во всяком случае, об этом подробнее на EmberConf .

Интеграция

Хотя нам еще предстоит проделать много работы (в основном оптимизации) над движком, мы считаем, что реализовали достаточно, чтобы охватить все основные варианты использования Ember. Итак, около двух месяцев назад мы начали интеграцию нового движка в Ember. Вы можете следить за этой мета-проблемой, чтобы узнать о нашем прогрессе.

Хотя пока еще невозможно использовать новый движок в реальных приложениях, мы ожидаем, что эта работа будет завершена относительно скоро. Ожидается, что после того, как мы закончим реализацию, это будет относительно безболезненное обновление для приложений, как и исходная миграция Handlebars на HTMLBars.

(Следует отметить, что возможность переключать флаг функции, вероятно, будет задействована _ до__ реализации всех существующих функций, поэтому она, вероятно, _не__ будет работать с вашим приложением без проблем с самого начала.)

Пожалуйста, отправьте половину

Итак, вы можете спросить: «Чем я могу помочь?»

Рад, что вы спросили! : boom:: sparkles:: fireworks:: tada:

На этом этапе самое большое значение, которое вы можете сделать, чтобы помочь, - это помочь перенести существующие тесты (и помочь просмотреть эти PR). Видите ли, у Ember есть довольно обширный набор тестов, который проверяет поведение «уровня представления». Проблема в том, что многие из этих тестов написаны способами, которые тесно связаны с существующей реализацией или иным образом используют устаревшую семантику (например, {{view.foo}} ), которая больше не поддерживается.

Чтобы быть уверенным, что мы не вызвали никаких регрессов, мы хотели бы иметь возможность запустить весь наш набор тестов как для текущего механизма рендеринга («htmlbars»), так и для Glimmer 2.

Мы написали новую систему тестирования, которая позволяет нам это делать. Я расскажу о технических деталях ниже, но основная идея состоит в том, что мы написали наши тестовые примеры на уровне абстракции, который инкапсулирует различия между двумя движками, позволяя одному и тому же коду в тестовых примерах работать с обеими реализациями.

Попутно мы также «модернизируем» существующие тесты в процессе, чтобы не полагаться на устаревшую семантику (если только они явно не проверяют эту семантику, и в этом случае мы оставим их в покое). Наша новая тестовая система также значительно упрощает и делает намного более приятным проведение тестов в «матричном стиле». Подробнее об этом ниже, но вот схема архитектуры высокого уровня:

В итоге тесты стали намного легче читать и обдумывать, и мы также значительно расширили охват. Это отличный результат для всех, но у нас осталось еще много тестов, и мы не можем быть уверены в том, что поставляем движок, пока все они не будут перенесены. Однако, если некоторые из вас могут помочь нам портировать тестовый файл каждый, к этому времени на следующей неделе мы будем в очень хорошей форме!

Как работает подвеска

Фактический механизм, который мы использовали, довольно низкотехнологичный. Возможно, вы слышали об этом, это называется символическими ссылками .

Внутри тестовой папки пакета ember-glimmer вы найдете файл с именем abstract-test-case.js , который также имеет символическую ссылку на то же место внутри пакета ember-htmlbars . Этот файл определяет API, которые мы используем для написания тестовых примеров. Поскольку этот файл используется совместно (символически связан) между обоими пакетами, он не содержит ничего конкретного о двух реализациях.

Вместо этого все различия абстрагируются путем импорта файлов (таких как import ... from './helpers' ), предоставленных каждым пакетом. В качестве альтернативы, каждый пакет также может переопределить определенные методы для «абстрактных» классов в test-case.js (см. Версии ember-glimmer vs 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»:

1. Начальный рендер

Визуализируйте шаблон, который вы хотите протестировать, с начальными значениями по вашему выбору ( this.render(..., { ... }) ) и убедитесь, что результат соответствует вашим ожиданиям. ( Пример )

1. Безоперационная повторная визуализация

Вызовите this.runTask(() => this.rerender()); без каких-либо изменений значений, затем подтвердите, что результат остался прежним. ( Пример )

1. Обновление (я) через мутации

Внесите некоторые изменения в значения, которые вы используете в шаблонах. ( Пример )

Вам следует попробовать:

• Разбейте обновления на несколько частей (т.е. несколько утверждений this.runTask +), если это имеет смысл. Это увеличивает шансы на обнаружение «сбивающих с толку» ошибок, когда обновление _ некоторых_ значений «сдувает» другую несвязанную часть шаблона или вызывает другие нежелательные эффекты.
• Если это имеет смысл, используйте «внутренние мутации». Когда значение представляет собой просто строку или другое примитивное значение, это не имеет значения, но когда вы имеете дело с объектом или массивом, это означает обновление значений «внутри» объекта / массива при сохранении объекта / массива в одна и та же. ( Пример массива, Пример объекта )
• Попробуйте различные формы «внутренних мутаций», если это имеет смысл. Когда есть несколько способов сделать это (например, 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
}

В других случаях нам удавалось определять общее поведение, извлекая некоторые общие суперклассы (помещая фактические тестовые примеры в суперкласс), и настраивая части, которые отличаются в подклассе. Это позволяет вам написать тестовые примеры один раз и автоматически запустить множество различных сценариев (тесты «Matrix Style»).

Лучшим примером, вероятно, является проверка условий ( if , unless и т. Д.). Фактический тестовый файл просто определяет стиль вызова шаблона и подкласс TogglingSyntaxConditionalsTest (расположенный в shared-conditional-tests.js ) и автоматически получает множество общих тестов.

Встроенные тесты «если / если» идут еще дальше, выполняя один и тот же набор тестовых примеров против 11 (!) Различных сценариев вызова.

Фактическая структура совместного использования была несколько трудной для достижения, и потребовалось некоторое время, чтобы созреть / получить правильное, но отдача от этого была огромной (базовые сценарии теперь разделяются между {{#with}} и {{#each}} также).

Унаследованная семантика

Многие из существующих тестов используют устаревшую семантику, такую ​​как представления, {{view.foo}} , {{#view}} , context , контроллеры и т. Д. В большинстве случаев это чисто случайно и просто результат написания теста в то время, когда эти примитивы были основным способом решения задач. В таких случаях вы обычно можете без проблем перенести их на новую проводку (которая вместо этого использует компоненты).

Если вы сомневаетесь, вы также можете провести тест, не перенесенный в первую итерацию вашего PR, и задать свои вопросы в строчном комментарии.

К attrs или нет attrs

Мы решили по умолчанию не использовать {{attrs.foo}} в тестах, в которых используются фигурные компоненты (а это почти все из них), а полагаться только на атрибуты, отраженные в свойстве с тем же именем (т.е. просто {{foo}} ). Если тест специально не _о_ тестирует attrs.* (вероятно, все они должны быть в одном файле), для согласованности обычно следует предпочесть {{foo}} а не {{attrs.foo}} . Вы всегда можете назвать такие вещи, как innerFoo vs outerFoo если чувствуете необходимость устранить неоднозначность.

См. Также https://locks.svbtle.com/to-attrs-or-not-to-attrs от @locks.

Предостережения

Иногда тесты, которые вы перенесли, могут не работать ни на Glimmer 2, ни на HTMLBars. (Если он не работает ни на одном из двигателей, возможно, вы сделали что-то не так.)

В случае, если это не работает в Glimmer 2, вероятно, потому, что мы еще не реализовали эту функцию полностью. (Например, мы реализовали поддержку базовых компонентов, но еще не реализовали attributeBindings .)

В этом случае все еще хорошо перенести тест в новый стиль, чтобы мы могли просто включить его, когда функция будет реализована. Чтобы временно отключить тест для Glimmer 2, вы можете просто заменить префикс @test в имени метода на @htmlbars (что означает «запустить это только в HTMLBars-only»). Вы также можете отключить весь модуль, добавив к его имени moduleFor префикс @htmlbars .

В некоторых редких случаях тест будет работать правильно на Glimmer 2, но не пройдет на HTMLBars. Вам следует дважды проверить правильность семантики, которую вы тестируете, но также вполне возможно, что в текущей реализации HTMLBars есть просто ошибка. (Обычно это происходит, когда мы тестируем некоторые функции HTMLBars с новым «матричным стилем», когда значения не обновляются правильно в некоторых крайних случаях.)

В этом случае вы можете точно так же пометить отдельный тестовый пример или весь модуль как @glimmer . Поскольку ожидается, что это будет довольно редко (и может потребоваться исправление ошибки), было бы полезно, если бы вы могли включить краткое описание проблем, с которыми вы сталкиваетесь, в строчный комментарий.

Примеры

Вот несколько отличных примеров, когда члены нашего сообщества помогали переносить существующие тесты:

• # 12920 Встроенный {{if}} helper
• # 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-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 tests] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/attr_nodes) (: lock: от @chancancode и @ Wycats)

Мы хотели бы поближе взглянуть на эти тесты и понять требования. На данный момент заблокирую его.

• [] [ compat tests] (https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat): ножницы:

Мы объявили, что прекратим поддержку устаревших аддонов к 2.6, поэтому нам не нужно будет поддерживать эти функции в Glimmer 2. Пожалуйста, откройте PR, чтобы удалить тесты и функции на главном сервере. (Для этого, вероятно, потребуется относительно глубокое знание кодовой базы.)

• [x] [ glimmer-component tests] (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 tests] (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 tests] (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 tests] (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 tests] (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] [если / если тесты] (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}} tests] (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 tests] (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 tests] (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 tests] (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 tests # 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 tests] (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 tests] (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 tests] (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] [тесты "параметров блока"] (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 tests] (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: от @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 от @ 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, автор: @chadhietala

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

• [Икс] [ test] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js) (: lock: от @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 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 от @ 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] [тест "пустого элемента"] (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) (: 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): ножницы: # 13149 by @chadhietala

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

• [] [Тест «Просмотр диспетчера узлов»] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js ): ножницы:: вопрос:

Реализация 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] [тесты "начальной загрузки"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js): question:: lock: @krisselden

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

• [] [тесты «помощника по поиску»] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/lookup-helper_test.js): lock: @mixonic

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

• [x] [тесты "render env"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js): scissors:: lock: https : //github.com/emberjs/ember.js/pull/13399 @mixonic

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

Вероятно, есть и другие тесты, которые нужно перенести. Если вы заметили что-то, что я пропустил, укажите это в комментариях.

Отзывы

Когда вы будете готовы отправить свой PR (пожалуйста, отправьте PR WIP!), Укажите эту проблему в описании PR, чтобы мы могли их рассмотреть.

Период времени

Мы хотим как можно скорее перенести как можно больше тестов. В идеале мы хотели бы перенести большую часть (если не все) тестов в течение следующих недель или двух.

Заранее спасибо за вашу помощь! : heart:: yellow_heart:: green_heart:: blue_heart:: purple_heart: