:recycle: :recycle: :recycle: Please consider the environment before printing this Github issue. :recycle: :recycle: :recycle:

The Backstory

@wycats and I (and many other people who have helped along the way) have been working on a rebuild of the rendering engine for the last six months, codenamed "Glimmer 2".

It started as a fork of htmlbars but almost every line of code has been rewritten (sometimes several times) by now. We distilled all the learnings from building the previous-generation rendering pipelines (handlebars, htmlbars, the original glimmer project, etc), resulting in an architecture that's simultaneously more fitting for Ember's use cases but is also more flexible and well-positioned for future extensions and other non-Ember use cases.

You can find the codez at https://github.com/tildeio/glimmer. It's (re)written in TypeScript, and I think it's pretty cool. Anyway, more on that at EmberConf.

The Integration

While there are still a lot of work (mostly optimizations) we would like to do on the engine, we believe we have implemented enough to cover all the basic Ember use cases. So about two months ago, we have started integrating the new engine into Ember proper. You can follow this meta-issue for our progress so-far.

While it is not yet possible to use the new engine in real apps just yet, we expect that work to be completed relatively soon. The expectation is that once we have finished the implementation, it will be a relatively painless, drop-in upgrade for apps, just like the original Handlebars to HTMLBars migration.

(It should be noted that the ability to toggle the feature flag will probably land _before_ all the existing features are implemented, so it will probably _not_ work seamless with your app from the get-go.)

Pls send halp

So, you might be wondering, "How can I help?"

I am glad you asked! :boom: :sparkles: :fireworks: :tada:

At this point, the highest value you can do to help is to help port the existing tests (and help reviewing these PRs). You see, Ember has a pretty extensive test suite that tests the "view layer" behavior. The problem is that a lot of these tests are written in ways that are quite coupled to the existing implementation or otherwise uses legacy semantics (such as {{view.foo}}) that are no longer supported.

In order to be certain that we did not cause any regressions, we would like to be able to run our entire test suite against both the current rendering engine ("htmlbars") and Glimmer 2.

We have written a new test harness that allow us to do just that. I will get into the technical details below, but the basic idea is that we have written our test cases against an abstraction layer that encapsulates the differences between the two engines, allowing the same code in the test cases to run against both implementations.

Along the way, we are also "modernizing" the existing tests in the process to not rely on legacy semantics (unless they appear to be explicitly testing those semantics, in which case we will leave them alone). Our new test harness also makes it much easier and much more pleasant to do "matrix style" tests. More on that below, but here is a high-level architecture diagram:

The net result is that the tests are now much easier to read and reason about, and we have also greatly increased coverage. This is great outcome for everybody, but we still have a lot more tests left, and we cannot feel confident shipping the engine without all of them being ported. However, if a few of you could help us port a test file each, we will be in very good shape by this time next week!

How the harness works

The actual mechanism we used is pretty low tech. You might have heard of it, it's called symbolic links.

Inside the test folder of ember-glimmer package, you will find a file called abstract-test-case.js, which is also symlinked to the same location inside the ember-htmlbars package. This file defines the APIs we use the write the test cases. Because this file is shared (symlinked) between both packages, it does not contain anything specific about the two implementations.

Instead, all the differences are abstracted by importing files (such as import ... from './helpers') provided by each package. Alternatively, each package can also override specific methods on the "abstract" classes in test-case.js (see the ember-glimmer vs ember-htmlbars versions).

(In a lot of cases, you might not even need to modify these files at all, but knowing that's how it works/where the work happen under-the-hood might be still be helpful if you run into issues.)

How the tests work

Since the engine is intended to be a drop-in upgrade for real apps, as long as we the tests are actually testing how these features are supposed to be used in the real world, there are no reason why the tests wouldn't run with both engines.

That's been our focus so far. You can see an example here.

This test is physically located inside the ember-glimmer directory, but it is symlinked to the same location in the ember-htmlbars directory (in fact, the entire directory is symlinked).

As you can see, the test imports this package-specific test-case.js, but otherwise is agnostic about the rendering engine implementation.

The process

In general, and at the high-level, the process looks like this:

1. Pick a test file to port (usually it's an existing test file somewhere in ember-htmlbars)
2. Make a new file inside ember-glimmer/tests/integration/... somewhere
3. Port each test case/module to the new file, while...
   
   
   
   • Using the new moduleFor and ES6 class format
   
   
   • Ensuring that each test go through the "I-N-U-R" cycle ("initial render -> no-op rerender -> update(s) via mutation(s) -> reset via replacement" cycle, more on this below)
   
   
   • Removing (ignoring) duplicated tests (or tests that are implicitly covered by the update cycle mentioned above)
   
   
4. Symlink the test back into the ember-htmlbars package, unless the parent folder is already a symlink in ember-htmlbars (like the concat test I showed above)
5. Remove the old file (unless it still contains some tests that cannot be ported)
6. Open a pull-request
7. To make it easy to review, add a line comment for each test case you removed, stating the rationale (e.g. it was ported to /it is now covered via /it was a duplication of /...). You can also feel free to add comments/questions on tests you are not sure about.

How to write good tests

Here are a few general tips/rules that you can follow to improve the test cases.

The "I-N-U-R" cycle

We would like each test to go through the "I-N-U-R" cycle:

1. Initial render

Render the template you want to test, with the initial values of your choice (this.render(..., { ... })) and assert the result is what you expect. (Example)

1. No-op re-render

Call this.runTask(() => this.rerender()); without any changes to the values, then assert that the result remain the same. (Example)

1. Update(s) via mutation(s)

Make some updates to the values you use in the templates. (Example)

You should try to:

• Break up the updates into multiple chunks (i.e. multiple this.runTask + assertion) if it makes sense. This increase chances of catching "clobbering" bugs where updating _some_ of the values will "blow away" another unrelated part of the template or causes other undesirable effects.
• Use "interior mutations" if it makes sense. When the value is just a string or other primitive value, this doesn't matter, but when you are dealing with an object or an array, this means updating the values "inside" of the object/array while keeping the object/array the same. (Array Example, Object Example)
• Try different forms of "interior mutations" if it makes sense. When there are more than one ways to do this (e.g. pushObject vs removing an item, etc), it's usually a good idea to try more than one of them. (Example)
  
  
  
  1. Reset via replacement
  
  

Reset to the original starting condition by replacing all the variables.

• Reset: this helps to catch bugs where we caches the original value of the text node and forgot to update the cache along the way. In that case when you change it to anything other than the original value, it would work fine; but when you change it back to the original value it will short-circuit the DOM code and do nothing.
• Replacement: again, if the values are simple primitive values like strings, then this doesn't make a difference. But if the values are objects/arrays, etc, this means replacing that object/array with another new object (as opposed to mutating its internal values). (Array Example, Object Example)

Avoid duplicating tests

It is easy to copy a test case a few times to test slightly different variations of the same thing (e.g. {{#if foo}} starting with true vs false, or the difference between a "POJO" vs an Ember.Object), and we have done that a lot in the existing tests.

Sometimes that's the best you can do, but there are a lot of problems with this. First it produces a large amount of tests physically in the file, making it hard to find things. Also, when someone need to add a new test, they will usually randomly pick one of the few variants, carrying over details/mistakes that doesn't make a lot of sense for the new scenario. When we fix bugs in one of the copies, we will probably forget the rest.

Usually, there are ways to avoid the duplication. For example, in the case of testing the different starting condition ({{#if foo}} against true and false), you can just test both starting conditions in the same test:

["@test 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
}

In other cases, we have been able to define shared behaviors by extracting some shared super classes (putting the actual test cases in the super class), and configure the parts that are different in the subclass. This allows you to write the test cases once, and automatically have them run many different scenarios (the "Matrix Style" tests).

The best example is probably the conditionals test (if, unless, etc). The actual test file simply defines the template invocation style and subclass TogglingSyntaxConditionalsTest (located in shared-conditional-tests.js) and automatically get many shared tests.

The "inline if/unless" tests takes this even further, running the same set of test cases against 11 (!) different invocation scenarios.

The actual structure of the sharing was somewhat difficult to arrive at, and took some time to mature/get right, but the payoff there was massive (the basic scenarios are now shared between {{#with}} and {{#each}} as well).

Legacy semantics

A lot of the existing tests uses legacy semantics like views, {{view.foo}}, {{#view}}, context, controllers, etc. Most of the times, this is purely incidental, and just a result of the test being written in a time where those primitives were the main way to do things. In those cases, you can usually port them to the new harness (which uses components instead) without problems.

When in doubt, you can also a test unported in the first iteration of your PR and ask your questions in a line comment.

To attrs or not to attrs

We decided to default to not using {{attrs.foo}} in tests that uses curly components (which is almost all of them) and rather rely just relying on the attrs being reflected onto the property with the same name (i.e. just {{foo}}). Unless the test is specifically _about_ testing attrs.* (those should probably all be in the same file), you should generally prefer {{foo}} rather than {{attrs.foo}} for consistency. You can always name things like innerFoo vs outerFoo if you feel the need to disambiguate.

See also https://locks.svbtle.com/to-attrs-or-not-to-attrs by @locks.

Caveats

Sometimes you the tests that you ported might not work on either Glimmer 2 or HTMLBars. (If it doesn't work on either engine, you probably did something wrong.)

In the case where it doesn't work on Glimmer 2, it's probably because we haven't implemented that feature completely yet. (For example, we have implemented basic components support but haven't implemented attributeBindings at this point.)

In this case, it is still good to port the test to the new style, so that we can simply enable it when the feature is implemented. To disable a test temporarily for Glimmer 2, you can simply replace the @test prefix in the method name to @htmlbars (which means "run this in HTMLBars-only"). You can also disable an entire module by prefixing its moduleFor name with @htmlbars.

In some rare cases, the test will work correctly on Glimmer 2 but does not pass on HTMLBars. You should double check that the semantics you are testing is correct, but it is also quite possible that there is simply a bug in the current implementation of HTMLBars. (This usually happens when we test some HTMLBars features with the new "matrix style", where the values do not update correctly in some edge cases.)

In that case, you can similarly flag an individual test case or an entire module as @glimmer. Since this is expected to be quite rare (and might require a bug fix), it would be helpful if you can include a brief description of the problems you encounter in a line comment.

Examples

Here are some of the great examples where our community members have helped port existing tests:

• #12920 Inline {{if}} helper
• #12927 {{#with}}
• #13019 Inline {{unless}}
• #13093 (hash) helper

As you can see, the earlier iterations was more difficult (we were still figuring out the shared test cases story), but the latter attempts were relatively straight forward. Thank you @GavinJoyce and @chadhietala for paving the way!

So... where do I start?

Here is a list of good starting points. If you are serious about working on one of these, you probably want to leave a comment below so that other people will know not to work on that. (If you ran out of time or encountered great difficult, please come back to "release the lock" and/or push your WIP work, so other people can pick it up!)

• [x] Basic content rendering tests #13141 by @chancancode

I don't know if this already exists. Please try to find it and port if it does. But otherwise, please create a new file for it (we already started something in https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js). The idea is we want to test "what happens if you put a strange thing into the DOM", e.g. {{foo}}, where foo is undefined, null, and object, etc. This is a prime target for the "Matrix Style" test, so you might want to study up on how the test harness works and draw ideas from the conditionals tests.

This should also absorb https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js too.

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

We would like to take a closer look at these tests and understand the requirements. Locking it for now.

• [ ] [compat tests](https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat) :scissors:

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 open PRs to remove the tests and the features on master. (This would probably require relatively deep knowledge of the codebase.)

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

This folder is unused. Please send a PR to remove it.

• Helpers (I think we should move them into 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 @Serabe)

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) :scissors: #13161 by @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 tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/debug_test.js) :scissors: #13129 by @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 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 tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_test.js) 🔒 by @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 by @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. @GavinJoyce can you confirm?

• [ ] [{{input}} tests](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 tests](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 tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/log_test.js) #13131 by @green-arrow

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 by @jheth and @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 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 tests](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 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 tests](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. @chadhietala 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 @chadhietala 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).

• "Integration" tests
  
  
  
  • [x] ["attribute binding" tests](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 @GavinJoyce or @chadhietala will know.)

• [x] ["attrs_lookup" tests](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] ["binding integration" tests](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" tests](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 tests](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] [component invocation tests](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] [component lifecycle tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js) (:lock: by @chancancode and @wycats)

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

• [x] ["escape" tests](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] ["helper lookup" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js) :scissors: #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] ["local lookup" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js) :scissors:

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

• [x] ["mutable binding" test](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) :scissors: #13144 by @HeroicEric

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

• [x] ["tagless views" test](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" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js) :scissors: #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" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (:lock: by @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" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js) :scissors: #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 @chadhietala

• [ ] ["View node manager" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js) :scissors: :question:

The implementation of the ViewNodManager probably need to stick around for a little longer because some internal things are still implemented as views in htmlbars, but this doesn't seem like it's testing anything important, so we can probably :scissors: it? @rwjblue can you confirm?

• "System" tests
  
  
  
  • [x] ["append templated view"](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js) :scissors: #13148 by @chadhietala
  
  

This is likely legacy. Please do investigate!

• [x] ["bootstrap" tests](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. @rwjblue 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" tests](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" tests](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/@wycats can you confirm and update this item?

There are probably other tests that needs to be ported too. If you noticed anything I missed, please mention them in the comments.

Reviews

Once you are ready to submit your PR (please feel free to submit WIP PRs!), please reference this issue in your PR description, so that we can review them.

Timeframe

We want to get as many test ported as soon as possible. Ideally, we would like to have most (if not all) of the tests ported within the next week or two.

Thank you in advance for your help! :heart: :yellow_heart: :green_heart: :blue_heart: :purple_heart: