: recycle:: recycle:: recycle: Veuillez tenir compte de l'environnement avant d'imprimer ce problème Github. : recycle:: recycle:: recycle:

La trame de fond

@wycats et moi (et beaucoup d'autres personnes qui ont aidé en cours de route) travaillons sur une reconstruction du moteur de rendu depuis six mois, sous le nom de code "Glimmer 2".

Cela a commencé comme un fork de htmlbars mais presque chaque ligne de code a été réécrite (parfois plusieurs fois) maintenant. Nous avons distillé toutes les leçons tirées de la construction des pipelines de rendu de la génération précédente (guidons, barres html, le projet Glimmer

Vous pouvez trouver le codez sur https://github.com/tildeio/glimmer. C'est (ré) écrit en TypeScript, et je pense que c'est plutôt cool. Quoi qu'il en soit, plus à ce sujet à EmberConf .

L'intégration

Bien qu'il y ait encore beaucoup de travail (principalement des optimisations) que nous aimerions faire sur le moteur, nous pensons avoir mis en œuvre suffisamment pour couvrir tous les cas d'utilisation de base d'Ember. Donc, il y a environ deux mois , nous avons commencé à intégrer le nouveau moteur dans Ember proprement dit. Vous pouvez suivre ce méta-numéro pour nos progrès jusqu'à présent.

Bien qu'il ne soit pas encore possible d'utiliser le nouveau moteur dans de vraies applications pour le moment, nous nous attendons à ce que ce travail soit terminé relativement bientôt. On s'attend à ce qu'une fois que nous ayons terminé l'implémentation, ce sera une mise à niveau relativement simple et rapide pour les applications, tout comme la migration originale de Handlebars vers HTMLBars.

(Il convient de noter que la possibilité de basculer l'indicateur de fonctionnalité arrivera probablement _avant_ que toutes les fonctionnalités existantes soient implémentées, donc elle ne fonctionnera probablement pas de manière transparente avec votre application dès le départ.)

Pls envoyer halp

Alors, vous vous demandez peut-être "Comment puis-je vous aider?"

Je suis ravi que vous posiez cette question! : boom:: sparkles:: feux d'artifice:: tada:

À ce stade, la valeur la plus élevée que vous puissiez faire pour aider est d'aider à porter les tests existants (et d'aider à réviser ces PR). Vous voyez, Ember a une suite de tests assez complète qui teste le comportement de la "couche de vue". Le problème est que beaucoup de ces tests sont écrits de manière assez couplée à l'implémentation existante ou utilisent une sémantique héritée (comme {{view.foo}} ) qui n'est plus prise en charge.

Afin d'être certain que nous n'avons causé aucune régression, nous aimerions pouvoir exécuter toute notre suite de tests avec le moteur de rendu actuel ("htmlbars") et Glimmer 2.

Nous avons écrit un nouveau harnais de test qui nous permet de faire exactement cela. Je vais entrer dans les détails techniques ci-dessous, mais l'idée de base est que nous avons écrit nos cas de test sur une couche d'abstraction qui encapsule les différences entre les deux moteurs, permettant au même code dans les cas de test de s'exécuter contre les deux implémentations.

En cours de route, nous «modernisons» également les tests existants dans le processus pour ne pas s'appuyer sur la sémantique héritée (à moins qu'ils semblent tester explicitement cette sémantique, auquel cas nous les laisserons seuls). Notre nouveau harnais de test rend également beaucoup plus facile et beaucoup plus agréable de faire des tests de type «matrice». Plus d'informations ci-dessous, mais voici un diagramme d'architecture de haut niveau:

Le résultat net est que les tests sont maintenant beaucoup plus faciles à lire et à raisonner, et nous avons également considérablement augmenté la couverture. C'est un excellent résultat pour tout le monde, mais il nous reste encore beaucoup de tests et nous ne pouvons pas nous sentir confiants en expédiant le moteur sans qu'ils soient tous portés. Cependant, si quelques-uns d'entre vous pouvaient nous aider à porter chacun un fichier de test, nous serons en très bonne forme la semaine prochaine!

Comment fonctionne le harnais

Le mécanisme réel que nous avons utilisé est assez basique. Vous en avez peut-être entendu parler, cela s'appelle des liens symboliques .

Dans le dossier de test du package ember-glimmer , vous trouverez un fichier appelé abstract-test-case.js , qui est également lié symboliquement au même emplacement dans le package ember-htmlbars . Ce fichier définit les API que nous utilisons pour écrire les cas de test. Comme ce fichier est partagé (lié symboliquement) entre les deux packages, il ne contient rien de spécifique sur les deux implémentations.

Au lieu de cela, toutes les différences sont résumées en important des fichiers (tels que import ... from './helpers' ) fournis par chaque package. Alternativement, chaque paquet peut aussi surcharger des méthodes spécifiques sur les classes "abstraites" dans test-case.js (voir les versions ember-glimmer vs ember-htmlbars ).

(Dans de nombreux cas, vous n'aurez peut-être même pas besoin de modifier ces fichiers du tout, mais savoir que c'est ainsi que cela fonctionne / où le travail se déroule sous le capot peut être toujours utile si vous rencontrez des problèmes.)

Comment fonctionnent les tests

Étant donné que le moteur est destiné à être une mise à niveau instantanée pour de vraies applications, tant que nous testons réellement comment ces fonctionnalités sont censées être utilisées dans le monde réel, il n'y a aucune raison pour que les tests ne s'exécutent pas avec les deux moteurs.

Cela a été notre objectif jusqu'à présent. Vous pouvez voir un exemple ici .

Ce test est physiquement situé dans le répertoire ember-glimmer , mais il est lié symboliquement au même emplacement dans le répertoire ember-htmlbars (en fait, le répertoire entier est lié symboliquement).

Comme vous pouvez le voir, le test importe ce test-case.js spécifique au package, mais sinon, il est indépendant de l'implémentation du moteur de rendu.

Le processus

En général, et au plus haut niveau, le processus ressemble à ceci:

1. Choisissez un fichier de test à porter (il s'agit généralement d'un fichier de test existant quelque part dans ember-htmlbars )
2. Créez un nouveau fichier quelque part dans ember-glimmer/tests/integration/...
3. Portez chaque scénario de test / module vers le nouveau fichier, tandis que ...
   
   
   
   • Utilisation du nouveau format de classe moduleFor et ES6
   
   
   • S'assurer que chaque test passe par le cycle "INUR" ("rendu initial -> rerender sans opération -> mise à jour (s) via mutation (s) -> réinitialisation via remplacement" cycle, plus d'informations ci-dessous)
   
   
   • Suppression (ignorant) des tests dupliqués (ou des tests qui sont implicitement couverts par le cycle de mise à jour mentionné ci-dessus)
   
   
4. Lien symbolique du test vers le package ember-htmlbars , sauf si le dossier parent est déjà un lien symbolique dans ember-htmlbars (comme le test concat que j'ai montré ci-dessus)
5. Supprimez l'ancien fichier (sauf s'il contient encore des tests qui ne peuvent pas être portés)
6. Ouvrir une pull-request
7. Pour faciliter la révision, ajoutez une ligne de commentaire pour chaque cas de test que vous avez supprimé, en indiquant la justification (par exemple, il a été porté/ il est maintenant couvert via/ c'était une duplication de/ ...). Vous pouvez également vous sentir libre d'ajouter des commentaires / questions sur des tests dont vous n'êtes pas sûr.

Comment rédiger de bons tests

Voici quelques conseils / règles générales que vous pouvez suivre pour améliorer les cas de test.

Le cycle "INUR"

Nous souhaitons que chaque test passe par le cycle "INUR":

1. Rendu initial

Rendez le modèle que vous voulez tester, avec les valeurs initiales de votre choix ( this.render(..., { ... }) ) et affirmez que le résultat est ce que vous attendez. ( Exemple )

1. Rendu sans opération

Appelez this.runTask(() => this.rerender()); sans aucune modification des valeurs, puis affirmez que le résultat reste le même. ( Exemple )

1. Mise à jour (s) via mutation (s)

Mettez à jour les valeurs que vous utilisez dans les modèles. ( Exemple )

Vous devriez essayer de:

• Divisez les mises à jour en plusieurs morceaux (c'est-à-dire plusieurs this.runTask + assertion) si cela a du sens. Cela augmente les chances d'attraper des bogues "écrasants" où la mise à jour de certaines des valeurs "emportera" une autre partie non liée du modèle ou provoquera d'autres effets indésirables.
• Utilisez des "mutations intérieures" si cela a du sens. Lorsque la valeur est juste une chaîne ou une autre valeur primitive, cela n'a pas d'importance, mais lorsque vous traitez avec un objet ou un tableau, cela signifie mettre à jour les valeurs "à l'intérieur" de l'objet / tableau tout en gardant l'objet / tableau le même. ( Exemple de tableau, exemple d' objet )
• Essayez différentes formes de «mutations intérieures» si cela a du sens. Quand il y a plus d'une façon de faire cela (par exemple pushObject vs supprimer un élément, etc.), c'est généralement une bonne idée d'essayer plusieurs d'entre elles. ( Exemple )
  
  
  
  1. Réinitialiser via le remplacement
  
  

Réinitialisez la condition de départ d'origine en remplaçant toutes les variables.

• Réinitialiser: cela aide à attraper les bogues où nous mettons en cache la valeur d'origine du nœud de texte et oublions de mettre à jour le cache en cours de route. Dans ce cas, lorsque vous le remplacez par une valeur autre que la valeur d'origine, cela fonctionnera correctement; mais lorsque vous le remettez à la valeur d'origine, il court-circuite le code DOM et ne fait rien.
• Remplacement: encore une fois, si les valeurs sont de simples valeurs primitives comme des chaînes, cela ne fait aucune différence. Mais si les valeurs sont des objets / tableaux, etc., cela signifie remplacer cet objet / tableau par un autre nouvel objet (par opposition à la mutation de ses valeurs internes). ( Exemple de tableau, exemple d' objet )

Évitez de dupliquer les tests

Il est facile de copier un cas de test plusieurs fois pour tester des variantes légèrement différentes de la même chose (par exemple {{#if foo}} commençant par vrai et faux, ou la différence entre un "POJO" et un Ember.Object ), et nous l'avons fait beaucoup dans les tests existants.

Parfois, c'est le mieux que vous puissiez faire, mais cela pose de nombreux problèmes. Tout d'abord, il produit une grande quantité de tests physiquement dans le fichier, ce qui rend difficile la recherche d'éléments. De plus, lorsque quelqu'un a besoin d'ajouter un nouveau test, il choisit généralement au hasard l'une des rares variantes, reportant des détails / erreurs qui n'ont pas beaucoup de sens pour le nouveau scénario. Lorsque nous corrigeons des bogues dans l'une des copies, nous oublierons probablement le reste.

Habituellement, il existe des moyens d'éviter la duplication. Par exemple, dans le cas du test des différentes conditions de départ ( {{#if foo}} contre true et false ), vous pouvez simplement tester les deux conditions de départ dans le même test:

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

Dans d'autres cas, nous avons pu définir des comportements partagés en extrayant certaines super classes partagées (en plaçant les cas de test réels dans la super classe), et en configurant les parties qui sont différentes dans la sous-classe. Cela vous permet d'écrire les cas de test une fois, et de leur faire exécuter automatiquement de nombreux scénarios différents (les tests «Matrix Style»).

Le meilleur exemple est probablement le test conditionnel ( if , unless , etc.). Le fichier de test réel définit simplement le style d'appel du modèle et la sous-classe TogglingSyntaxConditionalsTest (situé dans shared-conditional-tests.js ) et obtient automatiquement de nombreux tests partagés.

Les tests "en ligne si / à moins" vont encore plus loin, exécutant le même ensemble de cas de test contre 11 (!) Scénarios d'appel différents.

La structure réelle du partage a été quelque peu difficile à atteindre et a mis du temps à mûrir / à bien faire, mais le gain a été énorme (les scénarios de base sont maintenant partagés entre {{#with}} et {{#each}} ainsi que).

Sémantique héritée

Un grand nombre des tests existants utilisent une sémantique héritée comme les vues, {{view.foo}} , {{#view}} , context , les contrôleurs, etc. La plupart du temps, c'est purement accidentel, et résultat du test écrit à une époque où ces primitifs étaient le principal moyen de faire les choses. Dans ces cas, vous pouvez généralement les porter sur le nouveau faisceau (qui utilise des composants à la place) sans problème.

En cas de doute, vous pouvez également effectuer un test non rapporté dans la première itération de votre PR et poser vos questions dans un commentaire en ligne.

À attrs ou pas à attrs

Nous avons décidé de ne pas utiliser par défaut {{attrs.foo}} dans les tests qui utilisent des composants bouclés (ce qui est presque tous) et de nous fier uniquement aux attrs reflétés sur la propriété du même nom (c'est-à-dire juste {{foo}} ). À moins que le test ne soit spécifiquement _about_ testing attrs.* (ceux-ci devraient probablement tous être dans le même fichier), vous devriez généralement préférer {{foo}} plutôt que {{attrs.foo}} pour la cohérence. Vous pouvez toujours nommer des choses comme innerFoo vs outerFoo si vous ressentez le besoin de lever l'ambiguïté.

Voir aussi https://locks.svbtle.com/to-attrs-or-not-to-attrs par @locks.

Mises en garde

Parfois, les tests que vous avez portés peuvent ne pas fonctionner sur Glimmer 2 ou HTMLBars. (Si cela ne fonctionne pas sur l'un ou l'autre moteur, vous avez probablement fait quelque chose de mal.)

Dans le cas où cela ne fonctionne pas sur Glimmer 2, c'est probablement parce que nous n'avons pas encore complètement implémenté cette fonctionnalité. (Par exemple, nous avons implémenté le support des composants de base mais n'avons pas implémenté attributeBindings à ce stade.)

Dans ce cas, il est toujours bon de porter le test vers le nouveau style, afin que nous puissions simplement l'activer lorsque la fonctionnalité est implémentée. Pour désactiver temporairement un test pour Glimmer 2, vous pouvez simplement remplacer le préfixe @test dans le nom de la méthode par @htmlbars (ce qui signifie "exécuter ceci dans HTMLBars uniquement"). Vous pouvez également désactiver un module entier en préfixant son nom moduleFor avec @htmlbars .

Dans certains cas rares, le test fonctionnera correctement sur Glimmer 2 mais ne passera pas sur HTMLBars. Vous devriez vérifier que la sémantique que vous testez est correcte, mais il est également tout à fait possible qu'il y ait simplement un bogue dans l'implémentation actuelle de HTMLBars. (Cela se produit généralement lorsque nous testons certaines fonctionnalités HTMLBars avec le nouveau "style de matrice", où les valeurs ne sont pas mises à jour correctement dans certains cas extrêmes.)

Dans ce cas, vous pouvez également marquer un cas de test individuel ou un module entier comme @glimmer . Comme cela devrait être assez rare (et peut nécessiter une correction de bogue), il serait utile que vous puissiez inclure une brève description des problèmes que vous rencontrez dans un commentaire de ligne.

Exemples

Voici quelques-uns des bons exemples où les membres de notre communauté ont aidé à porter des tests existants:

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

Comme vous pouvez le voir, les itérations précédentes étaient plus difficiles (nous étions encore en train de comprendre l'histoire des cas de test partagés), mais les dernières tentatives étaient relativement simples. Merci @GavinJoyce et @chadhietala pour avoir

Alors ... par où commencer?

Voici une liste de bons points de départ. Si vous envisagez sérieusement de travailler sur l'un d'entre eux, vous voudrez probablement laisser un commentaire ci-dessous afin que d'autres personnes sachent qu'il ne faut pas y travailler. (Si vous manquez de temps ou rencontrez de grandes difficultés, veuillez revenir pour "libérer le verrou" et / ou pousser votre travail WIP, afin que d'autres personnes puissent le récupérer!)

• [x] Tests de rendu de contenu de base # 13141 par @chancancode

Je ne sais pas si cela existe déjà. Veuillez essayer de le trouver et de porter si c'est le cas. Mais sinon, créez un nouveau fichier pour celui-ci (nous avons déjà commencé quelque chose dans https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js) . L'idée est que nous voulons tester "ce qui se passe si vous mettez une chose étrange dans le DOM", par exemple {{foo}} , où foo est undefined , null , et objet, etc. C'est une cible de choix pour le test "Matrix Style", vous pouvez donc vouloir étudier le fonctionnement du faisceau de test et tirer des idées des tests conditionnels.

Cela devrait également absorber https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js.

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

Nous aimerions examiner de plus près ces tests et comprendre les exigences. Verrouiller pour l'instant.

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

Nous avons annoncé que nous mettrions fin à la prise en charge des anciens addons à partir de la version 2.6, nous n'aurons donc pas besoin de prendre en charge ces fonctionnalités dans Glimmer 2. Veuillez ouvrir les PR pour supprimer les tests et les fonctionnalités de master. (Cela nécessiterait probablement une connaissance relativement approfondie de la base de code.)

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

Ce dossier est inutilisé. Veuillez envoyer un PR pour le supprimer.

• Helpers (je pense que nous devrions les déplacer dans tests/integration/helpers )
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js): verrouiller :
  
  

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): ciseaux: # 13161 par @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 par @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] [tests d'assistance personnalisés] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js) # 13138 par @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): ciseaux: # 13129 par @ 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 par @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) 🔒 par @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 par @ 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] [tests si / sauf] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/if_unless_test.js)

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

• [] [ {{input}} tests] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/input_test.js) (: lock: by @ 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 par @ 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 par @green -La Flèche

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 par @jheth et @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 par @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 par @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. <strong i="5">@chadhietala</strong> can you confirm?

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

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

• Tests "d'intégration"
  
  
  
  • [x] [tests de "liaison d'attribut"] (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] [tests "attrs_lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js) # 13203 par @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] [tests "d'intégration de liaison"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js) # 13210 par @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] [tests "block params"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) # 13189 par @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 par @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] [tests d'appel de composant] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js) # 12890 par @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] [tests du cycle de vie des composants] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js) (: lock: by @chancancode et @ wycats)

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

• [x] [tests "d'échappement"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/escape_integration_test.js) # 13143 par @ 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] [test "helper lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): ciseaux: # 13147 par @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] [test "local lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): ciseaux:

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

• [x] [test de "liaison mutable"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/mutable_binding_test.js): verrou:

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): ciseaux: # 13144 par @HeroicEric

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

• [x] [test "vues sans balise"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js): ciseaux: # 13146 par @ 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] [test "élément vide"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js): ciseaux: # 13187 par @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] [test "willDestroyElement"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (: lock: par @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] [tests "avec + vue"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js): ciseaux: # 13149 par @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>

• [] [Test "Afficher le gestionnaire de nœuds"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js ): ciseaux:: question:

L'implémentation de ViewNodManager doit probablement rester un peu plus longtemps car certaines choses internes sont toujours implémentées sous forme de vues dans htmlbars, mais cela ne semble pas tester quelque chose d'important, donc nous pouvons probablement: il? @rwjblue pouvez-vous confirmer?

• Tests "système"
  
  
  
  • [x] ["Ajouter une vue modélisée"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js): ciseaux: # 13148 par @chadhietala
  
  

This is likely legacy. Please do investigate!

• [x] [tests "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.

• [] [tests "d'aide à la recherche"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/lookup-helper_test.js): verrou: @mixonic

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

• [x] [tests "render env"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js): ciseaux:: verrou: 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?

Il y a probablement d'autres tests qui doivent également être portés. Si vous avez remarqué quelque chose que j'ai manqué, veuillez le mentionner dans les commentaires.

Commentaires

Une fois que vous êtes prêt à soumettre votre PR (n'hésitez pas à soumettre vos PR WIP!), Veuillez faire référence à ce problème dans votre description de PR, afin que nous puissions les examiner.

Plage de temps

Nous voulons faire porter autant de tests que possible. Idéalement, nous aimerions avoir la plupart (sinon la totalité) des tests portés dans la semaine ou les deux prochaines.

Merci d'avance pour votre aide! : coeur:: coeur_ jaune:: coeur_ vert:: coeur_ bleu:: coeur_pourpre: