: reciclar:: reciclar:: reciclar: tenga en cuenta el medio ambiente antes de imprimir este número de Github. : reciclar:: reciclar:: reciclar:

La historia de fondo

@wycats y yo (y muchas otras personas que han ayudado en el camino) hemos estado trabajando en una reconstrucción del motor de renderizado durante los últimos seis meses, con el nombre en código "Glimmer 2".

Comenzó como una bifurcación de htmlbars, pero casi todas las líneas de código se han reescrito (a veces varias veces) hasta ahora. Destilamos todos los aprendizajes de la construcción de los canales de renderizado de la generación anterior (manillares, htmlbars, el proyecto original de destello , etc.), lo que resultó en una arquitectura que es simultáneamente más adecuada para los casos de uso de Ember, pero también más flexible y bien posicionada para futuras extensiones. y otros casos de uso que no pertenecen a Ember.

Puede encontrar el codez en https://github.com/tildeio/glimmer. Está (re) escrito en TypeScript, y creo que es bastante bueno. De todos modos, más sobre eso en EmberConf .

La integración

Si bien todavía hay mucho trabajo (principalmente optimizaciones) que nos gustaría hacer en el motor, creemos que hemos implementado lo suficiente para cubrir todos los casos de uso básicos de Ember. Hace unos dos meses , comenzamos a integrar el nuevo motor en Ember propiamente dicho. Puede seguir este meta-problema para conocer nuestro progreso hasta ahora.

Si bien todavía no es posible utilizar el nuevo motor en aplicaciones reales, esperamos que el trabajo se complete relativamente pronto. La expectativa es que una vez que hayamos terminado la implementación, será una actualización para aplicaciones relativamente sencilla e inmediata, al igual que la migración original de Handlebars a HTMLBars.

(Cabe señalar que la capacidad de alternar el indicador de función probablemente aterrizará _antes_ de que se implementen todas las funciones existentes, por lo que probablemente _no_ funcionará perfectamente con su aplicación desde el principio).

Por favor envíe halp

Entonces, quizás se esté preguntando, "¿Cómo puedo ayudar?"

¡Me alegro de que lo hayas preguntado! : boom:: destellos:: fuegos artificiales:: tada:

En este punto, el valor más alto que puede hacer para ayudar es ayudar a portar las pruebas existentes (y ayudar a revisar estos PR). Verá, Ember tiene un conjunto de pruebas bastante extenso que prueba el comportamiento de la "capa de vista". El problema es que muchas de estas pruebas están escritas de manera bastante acoplada a la implementación existente o utilizan semántica heredada (como {{view.foo}} ) que ya no son compatibles.

Para estar seguros de que no causamos ninguna regresión, nos gustaría poder ejecutar todo nuestro conjunto de pruebas contra el motor de renderizado actual ("htmlbars") y Glimmer 2.

Hemos escrito un nuevo arnés de prueba que nos permite hacer precisamente eso. Entraré en los detalles técnicos a continuación, pero la idea básica es que hemos escrito nuestros casos de prueba contra una capa de abstracción que encapsula las diferencias entre los dos motores, lo que permite que el mismo código en los casos de prueba se ejecute en ambas implementaciones.

En el camino, también estamos "modernizando" las pruebas existentes en el proceso para que no dependan de la semántica heredada (a menos que parezcan estar probando explícitamente esa semántica, en cuyo caso las dejaremos en paz). Nuestro nuevo arnés de prueba también hace que sea mucho más fácil y agradable realizar pruebas de "estilo matricial". Más sobre eso a continuación, pero aquí hay un diagrama de arquitectura de alto nivel:

El resultado neto es que las pruebas ahora son mucho más fáciles de leer y razonar, y también hemos aumentado considerablemente la cobertura. Este es un gran resultado para todos, pero todavía nos quedan muchas más pruebas, y no podemos estar seguros de enviar el motor sin que todos sean portados. Sin embargo, si algunos de ustedes pudieran ayudarnos a portar un archivo de prueba cada uno, ¡estaremos en muy buena forma para esta fecha la próxima semana!

Cómo funciona el arnés

El mecanismo real que usamos es de muy baja tecnología. Es posible que haya oído hablar de él, se llama enlaces simbólicos .

Dentro de la carpeta de prueba del paquete ember-glimmer , encontrará un archivo llamado abstract-test-case.js , que también está enlazado simbólicamente a la misma ubicación dentro del paquete ember-htmlbars . Este archivo define las API que usamos para escribir los casos de prueba. Debido a que este archivo se comparte (enlace simbólico) entre ambos paquetes, no contiene nada específico sobre las dos implementaciones.

En su lugar, todas las diferencias se resumen importando archivos (como import ... from './helpers' ) proporcionados por cada paquete. Alternativamente, cada paquete también puede anular métodos específicos en las clases "abstractas" en test-case.js (ver las versiones ember-glimmer vs ember-htmlbars ).

(En muchos casos, es posible que ni siquiera necesite modificar estos archivos, pero saber que así es como funciona / dónde ocurre el trabajo bajo el capó podría ser útil si tiene problemas).

Como funcionan las pruebas

Dado que el motor está destinado a ser una actualización inmediata para aplicaciones reales, siempre que las pruebas realmente estén probando cómo se supone que se usan estas funciones en el mundo real, no hay ninguna razón por la que las pruebas no se ejecuten ambos motores.

Ese ha sido nuestro enfoque hasta ahora. Puedes ver un ejemplo aquí .

Esta prueba está ubicada físicamente dentro del directorio ember-glimmer , pero está enlazada simbólicamente a la misma ubicación en el directorio ember-htmlbars (de hecho, todo el directorio está enlazado simbólicamente).

Como puede ver, la prueba importa este test-case.js específico del paquete, pero por lo demás es independiente de la implementación del motor de renderizado.

El proceso

En general, y en el nivel superior, el proceso se ve así:

1. Elija un archivo de prueba para portar (generalmente es un archivo de prueba existente en algún lugar de ember-htmlbars )
2. Cree un nuevo archivo dentro de ember-glimmer/tests/integration/... algún lugar
3. Transfiera cada caso / módulo de prueba al nuevo archivo, mientras ...
   
   
   
   • Usando el nuevo formato de clase moduleFor y ES6
   
   
   • Asegurarse de que cada prueba pase por el ciclo "INUR" ("procesamiento inicial -> reenvío sin operación -> actualización (es) mediante mutación (es) -> reinicio mediante reemplazo" ciclo, más sobre esto a continuación)
   
   
   • Eliminar (ignorar) pruebas duplicadas (o pruebas que están implícitamente cubiertas por el ciclo de actualización mencionado anteriormente)
   
   
4. Vuelva a vincular la prueba con el paquete ember-htmlbars , a menos que la carpeta principal ya sea un enlace simbólico en ember-htmlbars (como la prueba concat que mostré arriba)
5. Elimine el archivo antiguo (a menos que todavía contenga algunas pruebas que no se pueden migrar)
6. Abrir una solicitud de extracción
7. Para facilitar la revisión, agregue un comentario de línea para cada caso de prueba que eliminó, indicando el motivo (por ejemplo, se transfirió a/ ahora está cubierto a través de/ fue una duplicación de/ ...). También puede agregar comentarios / preguntas sobre las pruebas de las que no está seguro.

Cómo escribir buenas pruebas

A continuación, se incluyen algunos consejos / reglas generales que puede seguir para mejorar los casos de prueba.

El ciclo "INUR"

Nos gustaría que cada prueba pasara por el ciclo "INUR":

1. Render inicial

Renderice la plantilla que desea probar, con los valores iniciales de su elección ( this.render(..., { ... }) ) y afirme que el resultado es el que espera. ( Ejemplo )

1. Reproducción sin operación

Llame this.runTask(() => this.rerender()); sin ningún cambio en los valores, luego afirme que el resultado sigue siendo el mismo. ( Ejemplo )

1. Actualización (es) mediante mutación (es)

Realice algunas actualizaciones a los valores que usa en las plantillas. ( Ejemplo )

Deberías intentar:

• Divida las actualizaciones en varios fragmentos (es decir, múltiples this.runTask + aserción) si tiene sentido. Esto aumenta las posibilidades de detectar errores "aplastantes" en los que la actualización de _algunos_ de los valores "destruirá" otra parte no relacionada de la plantilla o provocará otros efectos no deseados.
• Utilice "mutaciones interiores" si tiene sentido. Cuando el valor es solo una cadena u otro valor primitivo, esto no importa, pero cuando se trata de un objeto o una matriz, esto significa actualizar los valores "dentro" del objeto / matriz mientras se mantiene el objeto / matriz mismo. ( Ejemplo de matriz , Ejemplo de objeto )
• Pruebe diferentes formas de "mutaciones interiores" si tiene sentido. Cuando hay más de una forma de hacer esto (por ejemplo, pushObject frente a eliminar un elemento, etc.), suele ser una buena idea probar más de una de ellas. ( Ejemplo )
  
  
  
  1. Restablecer mediante reemplazo
  
  

Restablezca la condición inicial original reemplazando todas las variables.

• Restablecer: esto ayuda a detectar errores cuando almacenamos en caché el valor original del nodo de texto y olvidamos actualizar la caché en el camino. En ese caso, cuando lo cambie por otro que no sea el valor original, funcionará bien; pero cuando lo vuelva a cambiar al valor original, cortocircuitará el código DOM y no hará nada.
• Reemplazo: nuevamente, si los valores son valores primitivos simples como cadenas, entonces esto no hace una diferencia. Pero si los valores son objetos / matrices, etc., esto significa reemplazar ese objeto / matriz con otro nuevo objeto (en lugar de mutar sus valores internos). ( Ejemplo de matriz , Ejemplo de objeto )

Evite la duplicación de pruebas

Es fácil copiar un caso de prueba varias veces para probar variaciones ligeramente diferentes de la misma cosa (por ejemplo, {{#if foo}} comenzando con verdadero o falso, o la diferencia entre un "POJO" y un Ember.Object ), y lo hemos hecho mucho en las pruebas existentes.

A veces eso es lo mejor que puede hacer, pero hay muchos problemas con esto. Primero, produce una gran cantidad de pruebas físicamente en el archivo, lo que dificulta encontrar cosas. Además, cuando alguien necesita agregar una nueva prueba, generalmente elegirá al azar una de las pocas variantes, llevando detalles / errores que no tienen mucho sentido para el nuevo escenario. Cuando arreglemos errores en una de las copias, probablemente olvidemos el resto.

Por lo general, hay formas de evitar la duplicación. Por ejemplo, en el caso de probar la condición inicial diferente ( {{#if foo}} contra true y false ), puede probar ambas condiciones iniciales en la misma prueba:

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

En otros casos, hemos podido definir comportamientos compartidos extrayendo algunas superclases compartidas (poniendo los casos de prueba reales en la superclase) y configurando las partes que son diferentes en la subclase. Esto le permite escribir los casos de prueba una vez y hacer que se ejecuten automáticamente en muchos escenarios diferentes (las pruebas de "Estilo de matriz").

El mejor ejemplo es probablemente la prueba de condicionales ( if , unless , etc.). El archivo de prueba real simplemente define el estilo de invocación de la plantilla y la subclase TogglingSyntaxConditionalsTest (ubicada en shared-conditional-tests.js ) y automáticamente obtiene muchas pruebas compartidas.

Las pruebas "en línea si / a menos que" llevan esto aún más lejos, ejecutando el mismo conjunto de casos de prueba en 11 (!) Escenarios de invocación diferentes.

La estructura real del intercambio fue algo difícil de llegar y tomó algo de tiempo para madurar / hacer bien, pero la recompensa fue enorme (los escenarios básicos ahora se comparten entre {{#with}} y {{#each}} también).

Semántica heredada

Muchas de las pruebas existentes utilizan semánticas heredadas como vistas, {{view.foo}} , {{#view}} , context , controladores, etc. La mayoría de las veces, esto es puramente incidental y solo un resultado de que la prueba se escribió en una época en la que esas primitivas eran la forma principal de hacer las cosas. En esos casos, normalmente puede trasladarlos al nuevo arnés (que utiliza componentes en su lugar) sin problemas.

En caso de duda, también puede hacer una prueba no declarada en la primera iteración de su PR y hacer sus preguntas en un comentario de línea.

A attrs o no a attrs

Decidimos por defecto no usar {{attrs.foo}} en las pruebas que usan componentes rizados (que son casi todos) y confiar en que los atributos se reflejen en la propiedad con el mismo nombre (es decir, solo {{foo}} ). A menos que la prueba sea específicamente _sobre_ probar attrs.* (probablemente todos deberían estar en el mismo archivo), generalmente debería preferir {{foo}} lugar de {{attrs.foo}} por coherencia. Siempre puede nombrar cosas como innerFoo vs outerFoo si siente la necesidad de eliminar la ambigüedad.

Consulte también https://locks.svbtle.com/to-attrs-or-not-to-attrs por @locks.

Advertencias

A veces, es posible que las pruebas que transfirió no funcionen en Glimmer 2 o HTMLBars. (Si no funciona en ninguno de los motores, probablemente hizo algo mal).

En el caso de que no funcione en Glimmer 2, probablemente se deba a que aún no hemos implementado esa función por completo. (Por ejemplo, hemos implementado el soporte de componentes básicos pero no hemos implementado attributeBindings en este momento).

En este caso, todavía es bueno portar la prueba al nuevo estilo, de modo que podamos simplemente habilitarlo cuando se implemente la función. Para deshabilitar una prueba temporalmente para Glimmer 2, simplemente puede reemplazar el prefijo @test en el nombre del método por @htmlbars (que significa "ejecutar esto solo en HTMLBars"). También puede deshabilitar un módulo completo prefijando su moduleFor nombre con @htmlbars .

En algunos casos raros, la prueba funcionará correctamente en Glimmer 2 pero no pasa en HTMLBars. Debe verificar que la semántica que está probando sea correcta, pero también es muy posible que simplemente haya un error en la implementación actual de HTMLBars. (Esto suele ocurrir cuando probamos algunas características de HTMLBars con el nuevo "estilo de matriz", donde los valores no se actualizan correctamente en algunos casos extremos).

En ese caso, puede marcar de manera similar un caso de prueba individual o un módulo completo como @glimmer . Dado que se espera que esto sea bastante raro (y podría requerir una corrección de errores), sería útil si puede incluir una breve descripción de los problemas que encuentre en un comentario de línea.

Ejemplos

Estos son algunos de los excelentes ejemplos en los que los miembros de nuestra comunidad han ayudado a portar pruebas existentes:

• # 12920 Inline {{if}} helper
• # 12927 {{#with}}
• # 13019 En línea {{unless}}
• # 13093 (hash) ayudante

Como puede ver, las iteraciones anteriores fueron más difíciles (todavía estábamos averiguando la historia de los casos de prueba compartidos), pero los últimos intentos fueron relativamente sencillos. ¡Gracias @GavinJoyce y @chadhietala por allanar el camino!

Entonces ... ¿por dónde empiezo?

Aquí hay una lista de buenos puntos de partida. Si se toma en serio trabajar en uno de estos, probablemente desee dejar un comentario a continuación para que otras personas sepan que no deben trabajar en eso. (Si se le acabó el tiempo o le resultó muy difícil, vuelva a "abrir el candado" y / o empuje su trabajo WIP, ¡para que otras personas puedan recogerlo!)

• [x] Pruebas de representación de contenido básico # 13141 por @chancancode

No sé si esto ya existe. Intente encontrarlo y portarlo si lo hace. Pero de lo contrario, cree un nuevo archivo para él (ya comenzamos algo en https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js) . La idea es que queremos probar "qué sucede si pones algo extraño en el DOM", por ejemplo, {{foo}} , donde foo es undefined , null , y objeto, etc. Este es un objetivo principal para la prueba de "Estilo de matriz", por lo que es posible que desee estudiar cómo funciona el arnés de prueba y extraer ideas de las pruebas condicionales.

Esto también debería absorber https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/hooks/text_node_test.js también.

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

Nos gustaría echar un vistazo más de cerca a estas pruebas y comprender los requisitos. Bloqueándolo por ahora.

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

Anunciamos que terminaremos el soporte para los complementos heredados en 2.6, por lo que no necesitaremos admitir estas funciones en Glimmer 2. Abra PR para eliminar las pruebas y las funciones en el maestro. (Esto probablemente requeriría un conocimiento relativamente profundo del código base).

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

Esta carpeta no se utiliza. Envíe un PR para eliminarlo.

• Ayudantes (creo que deberíamos moverlos a tests/integration/helpers )
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js): bloquear :
  
  

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) (: bloqueo: por @ Serabe)

I am pretty sure this will have to be `@htmlbars` for now.

• [x] [ collection prueba] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/collection_test.js): tijeras: # 13161 por @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 por @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] [pruebas de ayuda personalizadas] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/custom_helper_test.js) # 13138 por @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): tijeras: # 13129 por @ 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 por @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) 🔒 por @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 por @ 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] [si / salvo pruebas] (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) (: bloqueo: por @ 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 por @ 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 por @green -flecha

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 por @jheth y @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 pruebas # 13215 por @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 por @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) (: bloqueo: por @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 pruebas] (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) (: bloqueo: por @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).

• Pruebas de "integración"
  
  
  
  • [x] [pruebas de "enlace de atributos"] (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] [pruebas "attrs_lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/attrs_lookup_test.js) # 13203 por @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] [pruebas de "integración de enlace"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/binding_integration_test.js) # 13210 por @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] [pruebas de "block params"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/block_params_test.js) # 13189 por @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 por @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] [pruebas de invocación de componentes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_invocation_test.js) # 12890 por @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] [pruebas del ciclo de vida de los componentes] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js) (: bloqueo: por @chancancode y @ wycats)

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

• [x] [pruebas de "escape"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/escape_integration_test.js) # 13143 por @ 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] [prueba de "búsqueda de ayuda"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): tijeras: # 13147 por @chadhietala

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

• [X] [ prueba] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js) (: bloqueo: por @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] [prueba de "búsqueda local"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): tijeras:

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

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

The Glimmer 2 implementation might change the story a bit, locking for now.

• [x] [ select prueba] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/select_in_template_test.js): tijeras: # 13144 por @HeroicEric

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

• [x] [prueba de "vistas sin etiquetas"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js): tijeras: # 13146 por @ 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] [prueba de "elemento vacío"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js): tijeras: # 13187 por @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] [prueba "willDestroyElement"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (: bloqueo: por @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] [pruebas "con + vista"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js): tijeras: # 13149 de @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>

• [] [Prueba de "Ver administrador de nodos"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/node-managers/view-node-manager-test.js ): tijeras:: pregunta:

La implementación de ViewNodManager probablemente necesite quedarse un poco más porque algunas cosas internas todavía se implementan como vistas en htmlbars, pero esto no parece que esté probando nada importante, por lo que probablemente podamos: tijeras: ¿eso? @rwjblue, ¿puedes confirmar?

• Pruebas del "sistema"
  
  
  
  • [x] ["añadir vista de plantilla"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js): tijeras: # 13148 por @chadhietala
  
  

This is likely legacy. Please do investigate!

• [x] [pruebas "bootstrap"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/bootstrap_test.js): pregunta:: bloqueo: @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.

• [] [Pruebas de "ayuda de búsqueda"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/lookup-helper_test.js): bloqueo: @mixonic

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

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

Probablemente haya otras pruebas que también necesiten ser portadas. Si notó algo que me perdí, menciónelo en los comentarios.

Reseñas

Una vez que esté listo para enviar su PR (¡no dude en enviar WIP PR!), Haga referencia a este problema en su descripción de PR, para que podamos revisarlo.

Periodo de tiempo

Queremos que se transfieran tantas pruebas como sea posible. Idealmente, nos gustaría tener la mayoría (si no todas) de las pruebas portadas dentro de la próxima semana o dos.

¡Gracias de antemano por su ayuda! : heart:: yellow_heart:: green_heart:: blue_heart:: purple_heart: