: recyceln :: recyceln :: recyceln: Bitte berücksichtigen Sie die Umgebung, bevor Sie diese Github-Ausgabe drucken. : recyceln :: recyceln :: recyceln:

Die Hintergrundgeschichte

@wycats und ich (und viele andere Leute, die dabei geholfen haben) haben in den letzten sechs Monaten an einem Umbau der Rendering-Engine mit dem Codenamen "Glimmer 2" gearbeitet.

Es begann als eine Abzweigung von HTML-Balken, aber fast jede Codezeile wurde inzwischen (manchmal mehrmals) neu geschrieben. Wir haben alle Erkenntnisse aus dem Erstellen der Rendering-Pipelines der vorherigen Generation (Lenker, HTML-Balken, das ursprüngliche Glimmer-

Sie finden den Codez unter https://github.com/tildeio/glimmer. Es ist in TypeScript (neu) geschrieben und ich finde es ziemlich cool. Jedenfalls mehr dazu bei EmberConf .

Die Integration

Obwohl wir noch viel Arbeit (hauptsächlich Optimierungen) an der Engine erledigen möchten, glauben wir, dass wir genug implementiert haben, um alle grundlegenden Ember-Anwendungsfälle abzudecken. Vor ungefähr zwei Monaten haben wir begonnen, den neuen Motor in Ember zu integrieren. Sie können dieses Meta-Problem für unsere bisherigen Fortschritte verfolgen.

Obwohl es noch nicht möglich ist, die neue Engine in realen Apps zu verwenden, erwarten wir, dass die Arbeiten relativ bald abgeschlossen sein werden. Die Erwartung ist, dass es nach Abschluss der Implementierung ein relativ schmerzloses Drop-In-Upgrade für Apps sein wird, genau wie bei der ursprünglichen Migration von Lenkern zu HTMLBars.

(Es sollte beachtet werden, dass die Möglichkeit, das Feature-Flag umzuschalten, wahrscheinlich landet, bevor alle vorhandenen Features implementiert sind, sodass es wahrscheinlich von Anfang an nicht nahtlos mit Ihrer App funktioniert.)

Bitte senden Sie halp

Sie fragen sich vielleicht: "Wie kann ich helfen?"

Ich bin froh, dass du gefragt hast! : boom :: funkelt :: Feuerwerk :: tada:

Zu diesem Zeitpunkt besteht der höchste Wert, den Sie für die Unterstützung tun können, darin, die vorhandenen Tests zu portieren (und diese PRs zu überprüfen). Sie sehen, Ember hat eine ziemlich umfangreiche Testsuite, die das Verhalten der "Ansichtsebene" testet. Das Problem ist, dass viele dieser Tests auf eine Weise geschrieben wurden, die eng mit der vorhandenen Implementierung gekoppelt ist oder auf andere Weise Legacy-Semantik (wie {{view.foo}} ) verwendet, die nicht mehr unterstützt wird.

Um sicherzugehen, dass wir keine Regressionen verursacht haben, möchten wir unsere gesamte Testsuite sowohl für die aktuelle Rendering-Engine ("htmlbars") als auch für Glimmer 2 ausführen können.

Wir haben ein neues Testgeschirr geschrieben, mit dem wir genau das tun können. Ich werde auf die technischen Details unten eingehen, aber die Grundidee ist, dass wir unsere Testfälle gegen eine Abstraktionsschicht geschrieben haben, die die Unterschiede zwischen den beiden Engines kapselt, sodass der gleiche Code in den Testfällen für beide Implementierungen ausgeführt werden kann.

Auf dem Weg dorthin "modernisieren" wir auch die vorhandenen Tests, um uns nicht auf Legacy-Semantik zu verlassen (es sei denn, sie scheinen diese Semantik explizit zu testen. In diesem Fall lassen wir sie in Ruhe). Unser neues Testgeschirr macht es auch viel einfacher und angenehmer, Tests im "Matrix-Stil" durchzuführen. Mehr dazu weiter unten, aber hier ist ein Architekturdiagramm auf hoher Ebene:

Das Nettoergebnis ist, dass die Tests jetzt viel einfacher zu lesen und zu begründen sind, und wir haben auch die Abdeckung stark erhöht. Dies ist ein großartiges Ergebnis für alle, aber wir haben noch viel mehr Tests vor uns und können uns nicht sicher fühlen, den Motor zu versenden, ohne dass alle portiert werden. Wenn uns jedoch einige von Ihnen helfen könnten, jeweils eine Testdatei zu portieren, sind wir nächste Woche um diese Zeit in sehr guter Verfassung!

Wie das Geschirr funktioniert

Der eigentliche Mechanismus, den wir verwendet haben, ist ziemlich Low-Tech. Sie haben vielleicht davon gehört, es heißt symbolische Links .

Im Testordner des Pakets ember-glimmer finden Sie eine Datei mit dem Namen abstract-test-case.js , die ebenfalls mit demselben Speicherort im Paket ember-htmlbars verknüpft ist. Diese Datei definiert die APIs, mit denen wir die Testfälle schreiben. Da diese Datei von beiden Paketen gemeinsam genutzt (symlinked) wird, enthält sie keine spezifischen Informationen zu den beiden Implementierungen.

Stattdessen werden alle Unterschiede durch Importieren von Dateien (z. B. import ... from './helpers' ) abstrahiert, die von jedem Paket bereitgestellt werden. Alternativ kann jedes Paket auch bestimmte Methoden für die "abstrakten" Klassen in test-case.js überschreiben (siehe die Versionen ember-glimmer vs ember-htmlbars ).

(In vielen Fällen müssen Sie diese Dateien möglicherweise gar nicht ändern, aber zu wissen, wie es funktioniert / wo die Arbeit unter der Haube stattfindet, kann dennoch hilfreich sein, wenn Sie auf Probleme stoßen.)

Wie die Tests funktionieren

Da die Engine als Drop-In-Upgrade für echte Apps gedacht ist, gibt es keinen Grund, warum die Tests nicht ausgeführt werden, solange wir in den Tests tatsächlich testen, wie diese Funktionen in der realen Welt verwendet werden sollen beide Motoren.

Das war bisher unser Fokus. Hier sehen Sie ein Beispiel .

Dieser Test befindet sich physisch im Verzeichnis ember-glimmer , ist jedoch mit demselben Speicherort im Verzeichnis ember-htmlbars verknüpft (tatsächlich ist das gesamte Verzeichnis verknüpft).

Wie Sie sehen können, importiert der Test dieses paketspezifische test-case.js , ist aber ansonsten unabhängig von der Implementierung der Rendering-Engine.

Der Prozess

Im Allgemeinen und auf hoher Ebene sieht der Prozess folgendermaßen aus:

1. Wählen Sie eine zu portierende Testdatei aus (normalerweise handelt es sich um eine vorhandene Testdatei irgendwo in ember-htmlbars ).
2. Erstellen Sie irgendwo eine neue Datei in ember-glimmer/tests/integration/...
3. Portieren Sie jeden Testfall / jedes Modul in die neue Datei, während ...
   
   
   
   • Verwenden des neuen Klassenformats moduleFor und ES6
   
   
   • Sicherstellen, dass jeder Test den "INUR" -Zyklus durchläuft ("Erstes Rendern -> No-Op-Rerender -> Aktualisierung (en) über Mutation (en) -> Zurücksetzen durch Ersetzen" -Zyklus, mehr dazu weiter unten)
   
   
   • Entfernen (Ignorieren) doppelter Tests (oder Tests, die implizit durch den oben genannten Aktualisierungszyklus abgedeckt sind)
   
   
4. Verknüpfen Sie den Test wieder mit dem Paket ember-htmlbars , es sei denn, der übergeordnete Ordner ist bereits ein Symlink in ember-htmlbars (wie der oben gezeigte Concat-Test).
5. Entfernen Sie die alte Datei (es sei denn, sie enthält noch einige Tests, die nicht portiert werden können).
6. Öffnen Sie eine Pull-Anfrage
7. Fügen Sie zur Vereinfachung der Überprüfung einen Zeilenkommentar für jeden entfernten Testfall hinzu, in dem die Gründe angegeben sind (z. B. wurde er portiert)/ es wird jetzt über abgedeckt/ es war eine Vervielfältigung von/ ...). Sie können auch Kommentare / Fragen zu Tests hinzufügen, bei denen Sie sich nicht sicher sind.

Wie man gute Tests schreibt

Hier sind einige allgemeine Tipps / Regeln, die Sie befolgen können, um die Testfälle zu verbessern.

Der "INUR" -Zyklus

Wir möchten, dass jeder Test den "INUR" -Zyklus durchläuft:

1. Erstes Rendern

Rendern Sie die zu testende Vorlage mit den Anfangswerten Ihrer Wahl ( this.render(..., { ... }) ) und bestätigen Sie, dass das Ergebnis Ihren Erwartungen entspricht. ( Beispiel )

1. No-op-Re-Rendering

Rufen Sie this.runTask(() => this.rerender()); ohne die Werte zu ändern, und bestätigen Sie dann, dass das Ergebnis gleich bleibt. ( Beispiel )

1. Update (s) über Mutation (en)

Nehmen Sie einige Aktualisierungen an den Werten vor, die Sie in den Vorlagen verwenden. ( Beispiel )

Sie sollten versuchen:

• Teilen Sie die Updates in mehrere Teile auf (dh mehrere this.runTask + Zusicherungen), wenn dies sinnvoll ist. Dies erhöht die Wahrscheinlichkeit, dass "Clobbering" -Fehler auftreten, bei denen das Aktualisieren einiger Werte einen anderen nicht verwandten Teil der Vorlage "wegbläst" oder andere unerwünschte Effekte verursacht.
• Verwenden Sie "innere Mutationen", wenn es sinnvoll ist. Wenn der Wert nur eine Zeichenfolge oder ein anderer primitiver Wert ist, spielt dies keine Rolle. Wenn Sie sich jedoch mit einem Objekt oder Array befassen, bedeutet dies, dass die Werte "innerhalb" des Objekts / Arrays aktualisiert werden, während das Objekt / Array beibehalten wird gleich. ( Array-Beispiel , Objekt-Beispiel )
• Probieren Sie verschiedene Formen von "inneren Mutationen" aus, wenn dies sinnvoll ist. Wenn es mehr als eine Möglichkeit gibt, dies zu tun (z. B. pushObject gegenüber dem Entfernen eines Elements usw.), ist es normalerweise eine gute Idee, mehr als eine davon auszuprobieren. ( Beispiel )
  
  
  
  1. Durch Austausch zurücksetzen
  
  

Setzen Sie die ursprüngliche Startbedingung zurück, indem Sie alle Variablen ersetzen.

• Zurücksetzen: Dies hilft, Fehler zu erkennen, bei denen der ursprüngliche Wert des Textknotens zwischengespeichert und vergessen wird, den Cache auf dem Weg zu aktualisieren. In diesem Fall funktioniert es einwandfrei, wenn Sie es auf einen anderen Wert als den ursprünglichen Wert ändern. Wenn Sie ihn jedoch wieder auf den ursprünglichen Wert zurücksetzen, wird der DOM-Code kurzgeschlossen und es wird nichts unternommen.
• Ersetzung: Auch wenn die Werte einfache primitive Werte wie Zeichenfolgen sind, macht dies keinen Unterschied. Wenn es sich bei den Werten jedoch um Objekte / Arrays usw. handelt, bedeutet dies, dass dieses Objekt / Array durch ein anderes neues Objekt ersetzt wird (im Gegensatz zum Mutieren seiner internen Werte). ( Array-Beispiel , Objekt-Beispiel )

Vermeiden Sie doppelte Tests

Es ist einfach, einen Testfall einige Male zu kopieren, um leicht unterschiedliche Variationen derselben Sache zu testen (z. B. {{#if foo}} beginnend mit true gegen false oder den Unterschied zwischen einem "POJO" und einem Ember.Object ), und das haben wir in den bestehenden Tests viel getan.

Manchmal ist das das Beste, was Sie tun können, aber es gibt viele Probleme damit. Erstens erzeugt es eine große Anzahl von Tests physisch in der Datei, was es schwierig macht, Dinge zu finden. Wenn jemand einen neuen Test hinzufügen muss, wählt er normalerweise zufällig eine der wenigen Varianten aus und überträgt Details / Fehler, die für das neue Szenario nicht sehr sinnvoll sind. Wenn wir Fehler in einer der Kopien beheben, werden wir wahrscheinlich den Rest vergessen.

Normalerweise gibt es Möglichkeiten, die Duplizierung zu vermeiden. Wenn Sie beispielsweise die verschiedenen Startbedingungen testen ( {{#if foo}} gegen true und false ), können Sie einfach beide Startbedingungen im selben Test testen:

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

In anderen Fällen konnten wir gemeinsam genutzte Verhaltensweisen definieren, indem wir einige gemeinsam genutzte Superklassen extrahierten (die tatsächlichen Testfälle in die Superklasse einfügten) und die Teile konfigurierten, die sich in der Unterklasse unterscheiden. Auf diese Weise können Sie die Testfälle einmal schreiben und automatisch viele verschiedene Szenarien ausführen lassen (die "Matrix Style" -Tests).

Das beste Beispiel ist wahrscheinlich der Bedingungstest ( if , unless usw.). Die eigentliche Testdatei definiert einfach den Stil des Vorlagenaufrufs und die Unterklasse TogglingSyntaxConditionalsTest (in shared-conditional-tests.js ) und erhält automatisch viele gemeinsame Tests.

Der "Inline-Wenn / Wenn" -Test geht noch einen Schritt weiter und führt denselben Satz von Testfällen für 11 (!) Verschiedene Aufrufszenarien aus.

Die tatsächliche Struktur des Teilens war etwas schwierig zu erreichen und es dauerte einige Zeit, bis es reif / richtig war, aber die Auszahlung dort war massiv (die grundlegenden Szenarien werden jetzt zwischen {{#with}} und {{#each}} auch).

Legacy-Semantik

Viele der vorhandenen Tests verwenden Legacy-Semantik wie Ansichten, {{view.foo}} , {{#view}} , context , Controller usw. In den meisten Fällen handelt es sich um rein zufällige Tests und nur um eine Das Ergebnis des Tests wurde in einer Zeit geschrieben, in der diese Grundelemente die Hauptmethode waren. In diesen Fällen können Sie sie normalerweise problemlos an den neuen Kabelbaum (der stattdessen Komponenten verwendet) anschließen.

Im Zweifelsfall können Sie auch einen in der ersten Iteration Ihrer PR nicht portierten Test durchführen und Ihre Fragen in einem Zeilenkommentar stellen.

Zu attrs oder nicht zu attrs

Wir haben uns entschieden, in Tests, in denen geschweifte Komponenten verwendet werden (was fast alle sind), standardmäßig nicht {{attrs.foo}} zu verwenden, sondern uns nur darauf zu verlassen, dass die Attribute auf der gleichnamigen Eigenschaft reflektiert werden (dh nur {{foo}} ). Sofern es sich bei dem Test nicht speziell um das Testen von attrs.* (diese sollten sich wahrscheinlich alle in derselben Datei befinden), sollten Sie aus Gründen der Konsistenz im Allgemeinen {{foo}} anstelle von {{attrs.foo}} bevorzugen. Sie können immer Dinge wie innerFoo vs outerFoo benennen, wenn Sie das Bedürfnis haben, eindeutig zu sein.

Siehe auch https://locks.svbtle.com/to-attrs-or-not-to-attrs by @locks.

Vorsichtsmaßnahmen

Manchmal funktionieren die von Ihnen portierten Tests möglicherweise nicht mit Glimmer 2 oder HTMLBars. (Wenn es bei beiden Motoren nicht funktioniert, haben Sie wahrscheinlich etwas falsch gemacht.)

Falls es unter Glimmer 2 nicht funktioniert, liegt dies wahrscheinlich daran, dass wir diese Funktion noch nicht vollständig implementiert haben. (Zum Beispiel haben wir die Unterstützung grundlegender Komponenten implementiert, aber zu diesem Zeitpunkt noch nicht attributeBindings implementiert.)

In diesem Fall ist es immer noch gut, den Test auf den neuen Stil zu portieren, damit wir ihn einfach aktivieren können, wenn die Funktion implementiert wird. Um einen Test für Glimmer 2 vorübergehend zu deaktivieren, können Sie einfach das Präfix @test im Methodennamen durch @htmlbars ersetzen (was bedeutet, dass dies nur in HTMLBars ausgeführt wird). Sie können auch ein gesamtes Modul deaktivieren, indem Sie dem Namen moduleFor @htmlbars .

In einigen seltenen Fällen funktioniert der Test unter Glimmer 2 korrekt, gibt jedoch keine HTMLBars weiter. Sie sollten überprüfen, ob die Semantik, die Sie testen, korrekt ist. Es ist jedoch auch möglich, dass die aktuelle Implementierung von HTMLBars einfach einen Fehler enthält. (Dies geschieht normalerweise, wenn wir einige HTMLBars-Funktionen mit dem neuen "Matrixstil" testen, bei dem die Werte in einigen Randfällen nicht korrekt aktualisiert werden.)

In diesem Fall können Sie einen einzelnen Testfall oder ein gesamtes Modul auf ähnliche Weise als @glimmer . Da dies sehr selten zu erwarten ist (und möglicherweise eine Fehlerbehebung erfordert), ist es hilfreich, wenn Sie eine kurze Beschreibung der aufgetretenen Probleme in einen Zeilenkommentar aufnehmen können.

Beispiele

Hier sind einige der großartigen Beispiele, bei denen unsere Community-Mitglieder dazu beigetragen haben, vorhandene Tests zu portieren:

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

Wie Sie sehen können, waren die früheren Iterationen schwieriger (wir haben immer noch die gemeinsame Testfallgeschichte herausgefunden), aber die letzteren Versuche waren relativ einfach. Vielen Dank an @GavinJoyce und @chadhietala, dass sie den Weg

Also ... wo fange ich an?

Hier ist eine Liste guter Ausgangspunkte. Wenn Sie es ernst meinen, an einem dieser Themen zu arbeiten, möchten Sie wahrscheinlich unten einen Kommentar hinterlassen, damit andere Leute wissen, dass sie nicht daran arbeiten sollen. (Wenn Ihnen die Zeit ausgegangen ist oder Sie auf große Schwierigkeiten gestoßen sind, kehren Sie bitte zurück, um die Sperre aufzuheben und / oder Ihre WIP-Arbeit voranzutreiben, damit andere Personen sie abholen können!)

• [x] Grundlegende Tests zum Rendern von Inhalten

Ich weiß nicht, ob das schon existiert. Bitte versuchen Sie es zu finden und zu portieren, wenn dies der Fall ist. Andernfalls erstellen Sie bitte eine neue Datei dafür (wir haben bereits etwas unter https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js gestartet). . Die Idee ist, dass wir testen möchten, "was passiert, wenn Sie etwas Seltsames in das DOM einfügen", z. B. {{foo}} , wobei foo undefined , null Dies ist ein Hauptziel für den "Matrix Style" -Test. Daher möchten Sie möglicherweise die Funktionsweise des Testgurtes untersuchen und Ideen aus den bedingten Tests ziehen.

Dies sollte auch https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js absorbieren.

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

Wir möchten uns diese Tests genauer ansehen und die Anforderungen verstehen. Fürs Erste sperren.

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

Wir haben angekündigt, die Unterstützung für die Legacy-Addons um 2.6 zu beenden, sodass wir diese Funktionen in Glimmer 2 nicht unterstützen müssen. Öffnen Sie PRs, um die Tests und Funktionen auf dem Master zu entfernen. (Dies würde wahrscheinlich relativ tiefe Kenntnisse der Codebasis erfordern.)

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

Dieser Ordner wird nicht verwendet. Bitte senden Sie eine PR, um es zu entfernen.

• Helfer (Ich denke, wir sollten sie in tests/integration/helpers )
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js): sperren ::
  
  

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): Schere: # 13161 von @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 von @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] [benutzerdefinierte Hilfstests ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js)

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): Schere: # 13129 von @ 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 von @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) 🔒 von @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 von @ 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] [wenn / außer 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. <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 von @ 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 von @green -Pfeil

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 von @jheth und @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 von @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 von @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).

• "Integration" -Tests
  
  
  
  • [x] ["Attributbindungstests"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attribute_bindings_test.js) 🔒 @chadhietala # 13481
  
  

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

• [x] ["attrs_lookup" -Tests] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js) # 13203 von @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 zur "Bindungsintegration"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js) # 13210 von @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] ["Blockparameter" -Tests] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) # 13189 von @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 von @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] [Komponentenaufruftests] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js) # 12890 von @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] [Komponentenlebenszyklus-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 von @ 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): Schere: # 13147 von @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] ["lokaler Lookup" -Test] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): Schere:

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 "veränderbare Bindung"] (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): Schere: # 13144 von @HeroicEric

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

• [x] [Test "Tagless Views"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js): Schere: # 13146 von @ 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): Schere: # 13187 von @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: von @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): Schere: # 13149 von @ 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 "Knotenmanager anzeigen"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js ): Schere :: Frage:

Die Implementierung von ViewNodManager wahrscheinlich etwas länger dauern, da einige interne Dinge immer noch als Ansichten in HTML-Balken implementiert sind, aber dies scheint nichts Wichtiges zu testen, also können wir wahrscheinlich: Schere: es? @rwjblue kannst du bestätigen?

• "System" -Tests
  
  
  
  • [x] ["Vorlagenansicht anhängen"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js): Schere: # 13148 von @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): Frage :: lock:

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

• [] ["Lookup Helper" -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): Schere :: Sperre: 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?

Es gibt wahrscheinlich andere Tests, die ebenfalls portiert werden müssen. Wenn Sie etwas bemerkt haben, das ich verpasst habe, erwähnen Sie es bitte in den Kommentaren.

Bewertungen

Wenn Sie bereit sind, Ihre PR einzureichen (bitte senden Sie uns WIP-PRs!), Verweisen Sie in Ihrer PR-Beschreibung auf dieses Problem, damit wir sie überprüfen können.

Zeitfenster

Wir möchten, dass so viele Tests so schnell wie möglich portiert werden. Idealerweise möchten wir, dass die meisten (wenn nicht alle) Tests innerhalb der nächsten ein oder zwei Wochen portiert werden.

Vielen Dank im Voraus für deine Hilfe! : heart :: gelb_herz :: grün_herz :: blau_herz :: lila_herz: