：recycle：：recycle：：recycle：在打印此Github问题之前，请考虑环境。 ：recycle：：recycle：：recycle：

背景故事

@wycats和我（以及在此过程中提供帮助的其他许多人）在过去的六个月中一直在致力于渲染引擎的重建，代号为“ Glimmer 2”。

它起初是到目前为止几乎每一行代码都已被重写（有时是几次）。 我们从构建上一代渲染管道（把手，htmlbar，原始的glimmer

您可以在https://github.com/tildeio/glimmer上找到编码。 它是用TypeScript（重新）编写的，我认为它很酷。 无论如何，在EmberConf上可以了解更多。

整合

尽管我们仍然想在引擎上做很多工作（主要是优化），但我们相信我们已经实现了足够的能力来涵盖所有基本的Ember用例。 因此，大约两个月前，我们已经开始将新引擎集成到Ember中。 您可以按照此中继问题进行到目前为止的进展。

虽然目前尚无法在实际应用中使用新引擎，但我们希望这项工作会很快完成。 期望一旦我们完成了实现，它将是应用程序的一个相对轻松，直接的升级，就像原始的Handlebars到HTMLBars的迁移一样。

（应注意，切换功能标志的功能可能会先实现所有现有功能，因此可能一开始就无法与您的应用无缝配合。）

请发送halp

因此，您可能想知道，“我该如何帮助？”

我很高兴你问！ ：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与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与删除项目等）时，尝试不止一种方法通常是一个好主意。 （示例）
  
  
  
  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}} ，而是仅依赖于将attrs反映到具有相同名称的属性上（即仅{{foo}} ）。 除非测试专门针对attrs.* （可能应该都在同一个文件中）进行测试，否则为了保持一致性，通常应该首选{{foo}}而不是{{attrs.foo}} 。 如果您需要消除歧义，可以随时命名innerFoo vs 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上正常运行，但不会在HTMLBars上通过。 您应该仔细检查所测试的语义是否正确，但是在当前的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-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删除测试和master上的功能。 （这可能需要相对深厚的代码库知识。）

• [x] [ glimmer-component测试]（https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component）：剪刀： ＃13139 ， @洛坎

该文件夹未使用。 请发送公关以将其删除。

• 助手（我认为我们应该将它们移至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测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/collection_test.js）：剪刀： ＃13161通过@HeroicEric

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

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

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

• [x] [自定义帮助程序测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js） ＃13138 @zackthehuman

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

• [x] [ debug测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/debug_test.js）：剪刀： ＃13129由@ code0100fun

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

• [x] [ #each-in测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_in_test.js） ＃13136 @mmun

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

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

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

• [x] [ #each测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_test.js） 🔒

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] [如果/除非测试]（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 @加文·乔伊斯（GavinJoyce）

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

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

• [x] [ loc测试]（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 ，@ kiwiupover

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

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

• [x] [ unbound测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/unbound_test.js） ＃13137 @chadhietala

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

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

• [x] [ view测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/view_test.js）（：lock：by @chadhietala）

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

• [x] [ with测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/with_test.js）

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

• [x] [ yield测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/yield_test.js）（：lock：by @kiwiupover）

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

• “集成”测试
  
  
  
  • [x] [“属性绑定”测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attribute_bindings_test.js）🔒 @chadhietala ＃13481
  
  

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

• [x] [“ attrs_lookup”测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js） ＃13203 @Joelkang

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

• [x] [“绑定集成”测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js） ＃ 13210 @Joelkang

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

• [x] [“ block params”测试]（https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js） ＃13189 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 @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] [“转义”测试]（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通过@chadhietala

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

• [X] [ 测试]（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）：锁定：

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）：剪刀： ＃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） （：锁：@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 ，作者： @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中的视图实现，但这似乎并没有测试任何重要的东西，因此我们可以：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] [“ bootstrap”测试]（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）：剪刀：: 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说明中引用此问题，以便我们进行审核。

大体时间

我们希望尽快移植尽可能多的测试。 理想情况下，我们希望在下一两周内移植大部分（如果不是全部）测试。

预先感谢您的帮助！ ：heart：：yellow_heart：：green_heart：：blue_heart：：purple_heart：