{"action":"created","issue":{"url":"https://api.github.com/repos/emberjs/ember.js/issues/13127","repository_url":"https://api.github.com/repos/emberjs/ember.js","labels_url":"https://api.github.com/repos/emberjs/ember.js/issues/13127/labels{/name}","comments_url":"https://api.github.com/repos/emberjs/ember.js/issues/13127/comments","events_url":"https://api.github.com/repos/emberjs/ember.js/issues/13127/events","html_url":"https://github.com/emberjs/ember.js/issues/13127","id":142025082,"number":13127,"title":"[Pls send halp!] The Ultimate Glimmer 2 Test Porting Guide","user":{"login":"chancancode","id":55829,"avatar_url":"https://avatars.githubusercontent.com/u/55829?v=3","gravatar_id":"","url":"https://api.github.com/users/chancancode","html_url":"https://github.com/chancancode","followers_url":"https://api.github.com/users/chancancode/followers","following_url":"https://api.github.com/users/chancancode/following{/other_user}","gists_url":"https://api.github.com/users/chancancode/gists{/gist_id}","starred_url":"https://api.github.com/users/chancancode/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chancancode/subscriptions","organizations_url":"https://api.github.com/users/chancancode/orgs","repos_url":"https://api.github.com/users/chancancode/repos","events_url":"https://api.github.com/users/chancancode/events{/privacy}","received_events_url":"https://api.github.com/users/chancancode/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/emberjs/ember.js/labels/Help%20Wanted","name":"Help Wanted","color":"009800"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":30,"created_at":"2016-03-19T04:16:56Z","updated_at":"2016-03-30T15:26:39Z","closed_at":null,"body":":recycle: :recycle: :recycle: **Please consider the environment before printing this Github issue.** :recycle: :recycle: :recycle:\r\n\r\n## The Backstory\r\n\r\n@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\".\r\n\r\nIt started as a fork of [htmlbars](https://github.com/tildeio/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](https://github.com/emberjs/ember.js/pull/10501), 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.\r\n\r\nYou 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](http://emberconf.com/speakers.html#godfrey-chan).\r\n\r\n## The Integration\r\n\r\nWhile 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](https://github.com/emberjs/ember.js/pull/12772), we have started integrating the new engine into Ember proper. You can follow [this meta-issue](https://github.com/emberjs/ember.js/issues/12907) for our progress so-far.\r\n\r\nWhile 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.\r\n\r\n(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.)\r\n\r\n## Pls send halp\r\n\r\nSo, you might be wondering, \"How can I help?\"\r\n\r\nI am glad you asked! :boom: :sparkles: :fireworks: :tada: \r\n\r\nAt 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.\r\n\r\nIn 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.\r\n\r\nWe 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.\r\n\r\nAlong 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:\r\n\r\n![matrix](https://img.buzzfeed.com/buzzfeed-static/static/enhanced/webdr02/2013/8/5/10/anigif_enhanced-buzz-13846-1375714007-5.gif)\r\n\r\nThe 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!\r\n\r\n## How the harness works\r\n\r\nThe actual mechanism we used is pretty low tech. You might have heard of it, it's called [symbolic links](https://en.wikipedia.org/wiki/Symbolic_link).\r\n\r\nInside the test folder of `ember-glimmer` package, you will find a file called [`abstract-test-case.js`](https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/utils/abstract-test-case.js), which is also symlinked to the [same location](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/utils/abstract-test-case.js) 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.\r\n\r\nInstead, 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`](https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/utils/test-case.js) vs [`ember-htmlbars`](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/utils/test-case.js) versions).\r\n\r\n(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.)\r\n\r\n## How the tests work\r\n\r\nSince 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.\r\n\r\nThat's been our focus so far. You can see [an example here](https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/helpers/concat-test.js).\r\n\r\nThis test is physically located inside the `ember-glimmer` directory, but it is [symlinked to the same location](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helpers) in the `ember-htmlbars` directory (in fact, the entire directory is symlinked).\r\n\r\nAs you can see, the test imports this package-specific `test-case.js`, but otherwise is agnostic about the rendering engine implementation.\r\n\r\n## The process\r\n\r\nIn general, and at the high-level, the process looks like this:\r\n\r\n1. Pick a test file to port (usually it's an existing test file somewhere in `ember-htmlbars`)\r\n2. Make a new file inside `ember-glimmer/tests/integration/...` somewhere\r\n3. Port each test case/module to the new file, while...\r\n  * Using the new `moduleFor` and ES6 class format\r\n  * 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)\r\n  * Removing (ignoring) duplicated tests (or tests that are implicitly covered by the update cycle mentioned above)\r\n4. 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)\r\n5. Remove the old file (unless it still contains some tests that cannot be ported)\r\n6. Open a pull-request\r\n7. 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 <new test name>/it is now covered via <new test name>/it was a duplication of <another test>/...). You can also feel free to add comments/questions on tests you are not sure about.\r\n\r\n## How to write good tests\r\n\r\nHere are a few general tips/rules that you can follow to improve the test cases.\r\n\r\n### The \"I-N-U-R\" cycle\r\n\r\nWe would like each test to go through the \"I-N-U-R\" cycle:\r\n\r\n1. Initial render\r\n\r\n    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](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/helpers/concat-test.js#L12-L17))\r\n\r\n2. No-op re-render\r\n\r\n    Call `this.runTask(() => this.rerender());` without any changes to the values, then assert that the result remain the same. ([Example](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/helpers/concat-test.js#L19-L21))\r\n\r\n3. Update(s) via mutation(s)\r\n\r\n    Make some updates to the values you use in the templates. ([Example](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/helpers/concat-test.js#L23-L29))\r\n\r\n    You should try to:\r\n\r\n    * 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.\r\n\r\n    * 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](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/syntax/each-test.js#L65-L75), [Object Example](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/syntax/with-test.js#L202-L207))\r\n\r\n    * 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](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/syntax/each-test.js#L126-L135))\r\n\r\n4. Reset via replacement\r\n\r\n    Reset to the original starting condition by replacing all the variables.\r\n\r\n    * 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.\r\n\r\n    * 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](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/syntax/each-test.js#L81-L83), [Object Example](https://github.com/emberjs/ember.js/blob/08c94289ffebc7ef398af94a1fcc40d1bd09c6a7/packages/ember-glimmer/tests/integration/syntax/with-test.js#L209-L214))\r\n\r\n### Avoid duplicating tests\r\n\r\nIt 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.\r\n\r\nSometimes 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.\r\n\r\nUsually, 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:\r\n\r\n```js\r\n[\"@test if\"]() {\r\n  this.render(`{{#if cond1}}T{{else}}F{{/if}}{{#if cond2}}T{{else}}F{{/if}}`, { cond1: true, cond2: false });`\r\n\r\n  ... // follow the usual I-N-U-R cycle\r\n}\r\n```\r\n\r\nIn 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).\r\n\r\nThe best example is probably the conditionals test (`if`, `unless`, etc). The [actual test file](https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/syntax/if-unless-test.js) simply defines the template invocation style and subclass `TogglingSyntaxConditionalsTest` (located in [`shared-conditional-tests.js`](https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/utils/shared-conditional-tests.js)) and automatically get many shared tests.\r\n\r\nThe [\"inline if/unless\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/helpers/if-unless-test.js) takes this even further, running the same set of test cases against 11 (!) different invocation scenarios.\r\n\r\nThe 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).\r\n\r\n### Legacy semantics\r\n\r\nA 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.\r\n\r\nWhen in doubt, you can also a test unported in the first iteration of your PR and ask your questions in a line comment.\r\n\r\n### To `attrs` or not to `attrs`\r\n\r\nWe 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.\r\n\r\nSee also https://locks.svbtle.com/to-attrs-or-not-to-attrs by @locks.\r\n\r\n## Caveats \r\n\r\nSometimes 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.)\r\n\r\nIn 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.)\r\n\r\nIn 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`.\r\n\r\nIn 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.)\r\n\r\nIn 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.\r\n\r\n## Examples\r\n\r\nHere are some of the great examples where our community members have helped port existing tests:\r\n\r\n* #12920 Inline `{{if}}` helper\r\n* #12927 `{{#with}}`\r\n* #13019 Inline `{{unless}}`\r\n* #13093 `(hash)` helper\r\n\r\nAs 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! \r\n\r\n## So... where do I start?\r\n\r\nHere 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!)\r\n\r\n* [x] Basic content rendering tests ~~#13141~~ by @chancancode\r\n\r\n    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.\r\n\r\n   This should also absorb https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js too.\r\n\r\n* [ ] [`attr_nodes` tests](https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/attr_nodes) (:lock: by @chancancode and @wycats)\r\n\r\n    We would like to take a closer look at these tests and understand the requirements. Locking it for now.\r\n\r\n* [ ] [`compat` tests](https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/compat) :scissors: \r\n\r\n    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.)\r\n\r\n* [x] [`glimmer-component` tests](https://github.com/emberjs/ember.js/tree/master/packages/ember-htmlbars/tests/glimmer-component) :scissors: ~~#13139~~ by @lorcan \r\n\r\n    This folder is unused. Please send a PR to remove it.\r\n\r\n* Helpers (I think we should move them into `tests/integration/helpers`)\r\n\r\n    * [ ] [`-html-safe`](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js) :lock:\r\n\r\n        I'm not sure if this is needed for Glimmer 2. Locking for now.\r\n\r\n    * [ ] [`closure component helper`](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/closure_component_test.js)\r\n\r\n        I am pretty sure this will have to be `@htmlbars` for now.\r\n\r\n    * [x] [`collection` test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/collection_test.js) :scissors: ~~#13161~~ by @HeroicEric\r\n\r\n       This is legacy. Please open a PR to remove the test and any code you could find that implements the feature.\r\n\r\n    * [x] [`#component` helper](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/component_test.js) ~~#13140~~ by @GavinJoyce\r\n\r\n        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). \r\n\r\n    * [x] [custom helper tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js) ~~#13138~~ by @zackthehuman\r\n\r\n        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).\r\n\r\n    * [x] [`debug` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/debug_test.js) :scissors: ~~#13129~~ by @code0100fun \r\n\r\n        This is a duplicate of `log` as far as I can tell. See notes on `log` tests below.\r\n\r\n    * [x] [`#each-in` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_in_test.js) ~~#13136~~ by @mmun\r\n\r\n        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.) \r\n\r\n        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`).\r\n\r\n        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.\r\n\r\n    * [ ] [`#each` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/each_test.js)\r\n\r\n        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.) \r\n\r\n        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).\r\n\r\n        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.\r\n\r\n    * [ ] [`get` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/get_test.js) (:lock: by @ro0gr)\r\n\r\n        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`). \r\n\r\n        (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.)\r\n\r\n    *  [x] [if/unless tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/if_unless_test.js)\r\n\r\n        I believe this is already ported by @GavinJoyce. The rest are probably just legacy stuff that we can remove. @GavinJoyce can you confirm?\r\n\r\n    * [ ] [`{{input}}` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/input_test.js) (:lock: by @GavinJoyce)\r\n\r\n        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`). \r\n\r\n        (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™.)\r\n\r\n    * [x] [`loc` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/loc_test.js) ~~#13129~~ by @code0100fun \r\n\r\n        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`.\r\n\r\n    * [x] [`log` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/log_test.js) ~~#13131~~ by @green-arrow\r\n\r\n        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.\r\n\r\n    * [ ] [`partial` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/partial_test.js)\r\n\r\n        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`.\r\n\r\n    * [ ] [`text_area` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/text_area_test.js)\r\n\r\n        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`). \r\n\r\n        (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™.)\r\n\r\n    * [ ] [`unbound` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/unbound_test.js) (:lock: by @chadhietala)\r\n\r\n        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`). \r\n\r\n        (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.)\r\n\r\n    * [ ] [`view` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/view_test.js)\r\n\r\n        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.)\r\n\r\n    *  [x] [`with` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/with_test.js)\r\n\r\n        I believe this is already ported by @chadhietala. The rest are probably just legacy stuff that we can remove. @chadhietala can you confirm?\r\n\r\n    * [ ] [`yield` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/yield_test.js) (:lock: by @kiwiupover)\r\n\r\n        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).\r\n\r\n* \"Integration\" tests\r\n\r\n    * [ ] [\"attribute binding\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attribute_bindings_test.js) :question: \r\n\r\n        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.)\r\n\r\n    * [ ] [\"attrs_lookup\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js) (:lock: by @Joelkang)\r\n\r\n        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.\r\n\r\n    * [ ] [\"binding integration\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js) \r\n\r\n        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!\r\n\r\n    * [ ] [\"block params\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) (:lock: by @Joelkang)\r\n\r\n        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.\r\n\r\n    * [ ] [`elementId` tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_element_id_test.js) \r\n\r\n        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!\r\n\r\n        (If we start adding more tests for components, it probably makes sense to start splitting them up into different modules/files.)\r\n\r\n    * [ ] [component invocation tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js) (:lock: by @Serabe in #12890)\r\n\r\n        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.\r\n\r\n    * [ ] [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)\r\n\r\n        Most of these functionality are not yet implemented in Glimmer 2, so you might have to `@htmlbars` the entire module.\r\n\r\n    * [ ] [\"escape\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/escape_integration_test.js) (:lock: by @code0100fun)\r\n\r\n        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.\r\n\r\n    * [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\r\n\r\n        I think this must already be tested in the helpers test? Please do investigate and open a PR to remove if true.\r\n\r\n    * [ ] [\\<input\\> test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js)  (:lock: by @paddyobrien)\r\n\r\n        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.\r\n\r\n    * [ ] [\"local lookup\" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js) :scissors: \r\n\r\n        I'm not sure if this is implemented in Glimmer 2 yet. Please port the test cases and flag with `@htmlbars` as needed.\r\n\r\n    * [ ] [\"mutable binding\" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/mutable_binding_test.js) :lock: \r\n\r\n        The Glimmer 2 implementation might change the story a bit, locking for now.\r\n\r\n    * [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\r\n\r\n       This is legacy. Please open a PR to remove the test and any code you could find that implements the feature.\r\n\r\n    * [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\r\n\r\n       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.\r\n\r\n    * [ ] [\"void element\" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js) :scissors: (:lock: by @MatrixZ)\r\n\r\n       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.\r\n\r\n    * [ ] [\"willDestroyElement\" test](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (:lock: by @krisselden)\r\n\r\n       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`.\r\n\r\n    * [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\r\n\r\n        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 \r\n\r\n* [ ] [\"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: \r\n\r\n    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?\r\n\r\n* \"System\" tests\r\n\r\n    * [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\r\n\r\n        This is likely legacy. Please do investigate!\r\n\r\n    * [ ] [\"bootstrap\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js) :question: :lock: \r\n\r\n        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.\r\n\r\n    * [ ] [\"lookup helper\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/lookup-helper_test.js)\r\n\r\n        Please do investigate what this is testing, and see if it could be merged into the helpers integration tests.\r\n\r\n    * [ ] [\"render env\" tests](https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js) :scissors: :lock: \r\n\r\n        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?\r\n\r\nThere are probably other tests that needs to be ported too. If you noticed anything I missed, please mention them in the comments.\r\n\r\n## Reviews\r\n\r\nOnce 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.\r\n\r\n## Timeframe\r\n\r\nWe 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.\r\n\r\nThank you in advance for your help! :heart: :yellow_heart: :green_heart: :blue_heart: :purple_heart: "},"comment":{"url":"https://api.github.com/repos/emberjs/ember.js/issues/comments/203487346","html_url":"https://github.com/emberjs/ember.js/issues/13127#issuecomment-203487346","issue_url":"https://api.github.com/repos/emberjs/ember.js/issues/13127","id":203487346,"user":{"login":"kiwiupover","id":647691,"avatar_url":"https://avatars.githubusercontent.com/u/647691?v=3","gravatar_id":"","url":"https://api.github.com/users/kiwiupover","html_url":"https://github.com/kiwiupover","followers_url":"https://api.github.com/users/kiwiupover/followers","following_url":"https://api.github.com/users/kiwiupover/following{/other_user}","gists_url":"https://api.github.com/users/kiwiupover/gists{/gist_id}","starred_url":"https://api.github.com/users/kiwiupover/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kiwiupover/subscriptions","organizations_url":"https://api.github.com/users/kiwiupover/orgs","repos_url":"https://api.github.com/users/kiwiupover/repos","events_url":"https://api.github.com/users/kiwiupover/events{/privacy}","received_events_url":"https://api.github.com/users/kiwiupover/received_events","type":"User","site_admin":false},"created_at":"2016-03-30T15:26:38Z","updated_at":"2016-03-30T15:26:38Z","body":"#13213 is open for the `{{yield}}` tests\r\n"}}