: reciclar:: reciclar:: reciclar: Considere o meio ambiente antes de imprimir este problema do Github. : reciclar:: reciclar:: reciclar:

A História de Fundo

@wycats e eu (e muitas outras pessoas que ajudaram ao longo do caminho) estivemos trabalhando na reconstrução do mecanismo de renderização nos últimos seis meses, com o codinome "Glimmer 2".

Tudo começou como um fork de htmlbars, mas quase todas as linhas de código foram reescritas (às vezes várias vezes) até agora. Nós destilamos todos os aprendizados da construção de pipelines de renderização da geração anterior (guidão, htmlbars, o projeto de brilho original , etc), resultando em uma arquitetura que é simultaneamente mais adequada para os casos de uso do Ember, mas também é mais flexível e bem posicionada para futuras extensões e outros casos de uso não-Ember.

Você pode encontrar o codez em https://github.com/tildeio/glimmer. É (re) escrito em TypeScript, e acho muito legal. Enfim, mais sobre isso na EmberConf .

A integração

Embora ainda haja muito trabalho (principalmente otimizações) que gostaríamos de fazer no mecanismo, acreditamos que implementamos o suficiente para cobrir todos os casos de uso básicos do Ember. Então, cerca de dois meses atrás , começamos a integrar o novo motor ao Ember propriamente dito. Você pode acompanhar este meta-problema para ver nosso progresso até agora.

Embora ainda não seja possível usar o novo mecanismo em aplicativos reais, esperamos que esse trabalho seja concluído em breve. A expectativa é que, assim que terminarmos a implementação, será uma atualização relativamente indolor para aplicativos, assim como a migração de Handlebars para HTMLBars original.

(Deve-se observar que a capacidade de alternar o sinalizador de recurso provavelmente atingirá _antes_ de todos os recursos existentes serem implementados, então provavelmente _não_ funcionará perfeitamente com seu aplicativo desde o início.)

Por favor, envie halp

Então, você deve estar se perguntando: "Como posso ajudar?"

Estou feliz que você perguntou! : boom:: brilha:: fireworks:: tada:

Neste ponto, o valor mais alto que você pode fazer para ajudar é ajudar a portar os testes existentes (e ajudar a revisar esses PRs). Veja, o Ember tem um conjunto de testes bastante extenso que testa o comportamento da "camada de visão". O problema é que muitos desses testes são escritos de maneiras bastante acopladas à implementação existente ou usam semânticas legadas (como {{view.foo}} ) que não são mais suportadas.

Para ter certeza de que não causamos nenhuma regressão, gostaríamos de poder rodar nosso conjunto de testes inteiro tanto no motor de renderização atual ("htmlbars") e no Glimmer 2.

Escrevemos um novo equipamento de teste que nos permite fazer exatamente isso. Entrarei em detalhes técnicos abaixo, mas a ideia básica é que escrevemos nossos casos de teste em uma camada de abstração que encapsula as diferenças entre os dois motores, permitindo que o mesmo código nos casos de teste seja executado em ambas as implementações.

Ao longo do caminho, também estamos "modernizando" os testes existentes no processo para não dependerem da semântica legada (a menos que pareçam estar testando explicitamente essa semântica, caso em que os deixaremos em paz). Nosso novo equipamento de teste também torna muito mais fácil e agradável fazer testes de "estilo de matriz". Mais sobre isso abaixo, mas aqui está um diagrama de arquitetura de alto nível:

O resultado líquido é que agora os testes são muito mais fáceis de ler e raciocinar, e também aumentamos muito a cobertura. Este é um ótimo resultado para todos, mas ainda temos muito mais testes pela frente, e não podemos nos sentir confiantes em enviar o motor sem que todos sejam portados. No entanto, se alguns de vocês pudessem nos ajudar a portar um arquivo de teste cada, estaremos em muito boa forma na próxima semana!

Como funciona o arnês

O mecanismo real que usamos é de tecnologia muito baixa. Você deve ter ouvido falar dele, é chamado de links simbólicos .

Dentro da pasta de teste do pacote ember-glimmer , você encontrará um arquivo chamado abstract-test-case.js , que também tem um link simbólico para o mesmo local dentro do pacote ember-htmlbars . Este arquivo define as APIs que usamos para escrever os casos de teste. Como esse arquivo é compartilhado (com link simbólico) entre os dois pacotes, ele não contém nada específico sobre as duas implementações.

Em vez disso, todas as diferenças são abstraídas importando arquivos (como import ... from './helpers' ) fornecidos por cada pacote. Alternativamente, cada pacote também pode substituir métodos específicos nas classes "abstratas" em test-case.js (consulte as versões ember-glimmer vs ember-htmlbars ).

(Em muitos casos, você pode nem precisar modificar esses arquivos, mas saber que é assim que funciona / onde o trabalho acontece nos bastidores ainda pode ser útil se você tiver problemas.)

Como funcionam os testes

Uma vez que o motor se destina a ser uma atualização imediata para aplicativos reais, contanto que os testes estejam realmente testando como esses recursos devem ser usados ​​no mundo real, não há razão para que os testes não sejam executados com ambos os motores.

Esse tem sido nosso foco até agora. Você pode ver um exemplo aqui .

Este teste está fisicamente localizado dentro do diretório ember-glimmer , mas tem um link simbólico para o mesmo local no diretório ember-htmlbars (na verdade, todo o diretório tem um link simbólico).

Como você pode ver, o teste importa este test-case.js específico do pacote, mas por outro lado é agnóstico quanto à implementação do mecanismo de renderização.

O processo

Em geral, e em alto nível, o processo se parece com este:

1. Escolha um arquivo de teste para portar (geralmente é um arquivo de teste existente em algum lugar em ember-htmlbars )
2. Faça um novo arquivo dentro de ember-glimmer/tests/integration/... algum lugar
3. Transfira cada caso / módulo de teste para o novo arquivo, enquanto ...
   
   
   
   • Usando o novo formato de classe moduleFor e ES6
   
   
   • Garantir que cada teste passe pelo ciclo "INUR" (ciclo "renderização inicial -> renderizar novamente -> atualização (ões) via mutação (ões) -> reinicializar via substituição", mais sobre isso abaixo)
   
   
   • Remover (ignorar) testes duplicados (ou testes que são implicitamente cobertos pelo ciclo de atualização mencionado acima)
   
   
4. Faça um link simbólico do teste de volta para o pacote ember-htmlbars , a menos que a pasta pai já seja um link simbólico em ember-htmlbars (como o teste de concat que mostrei acima)
5. Remova o arquivo antigo (a menos que ainda contenha alguns testes que não podem ser transferidos)
6. Abra uma solicitação de pull
7. Para facilitar a revisão, adicione um comentário de linha para cada caso de teste removido, declarando o motivo (por exemplo, foi transferido para/ agora está coberto por/ era uma duplicação de/ ...). Você também pode ficar à vontade para adicionar comentários / perguntas sobre os testes sobre os quais não tem certeza.

Como escrever bons testes

Aqui estão algumas dicas / regras gerais que você pode seguir para melhorar os casos de teste.

O ciclo "INUR"

Gostaríamos que cada teste passasse pelo ciclo "INUR":

1. Renderização inicial

Renderize o modelo que você deseja testar, com os valores iniciais de sua escolha ( this.render(..., { ... }) ) e afirme que o resultado é o que você espera. ( Exemplo )

1. Remoção sem operação

Chame this.runTask(() => this.rerender()); sem nenhuma alteração nos valores e, em seguida, afirme que o resultado permanece o mesmo. ( Exemplo )

1. Atualização (ões) por meio de mutação (ões)

Faça algumas atualizações nos valores que você usa nos modelos. ( Exemplo )

Você deve tentar:

• Divida as atualizações em vários pedaços (ou seja, várias asserções this.runTask +) se fizer sentido. Isso aumenta as chances de detectar bugs de "destruição" em que a atualização de _alguns_ dos valores "apagará" outra parte não relacionada do modelo ou causará outros efeitos indesejáveis.
• Use "mutações interiores" se fizer sentido. Quando o valor é apenas uma string ou outro valor primitivo, isso não importa, mas quando você está lidando com um objeto ou um array, isso significa atualizar os valores "dentro" do objeto / array enquanto mantém o objeto / array mesmo. ( Exemplo de matriz , Exemplo de objeto )
• Experimente diferentes formas de "mutações interiores" se fizer sentido. Quando há mais de uma maneira de fazer isso (por exemplo, pushObject vs remover um item, etc), geralmente é uma boa ideia tentar mais de uma delas. ( Exemplo )
  
  
  
  1. Redefinir por substituição
  
  

Redefina para a condição inicial original substituindo todas as variáveis.

• Redefinir: isso ajuda a detectar erros em que armazenamos em cache o valor original do nó de texto e esquecemos de atualizar o cache ao longo do caminho. Nesse caso, quando você alterá-lo para algo diferente do valor original, funcionará bem; mas quando você o altera de volta para o valor original, ele causa um curto-circuito no código DOM e não faz nada.
• Substituição: novamente, se os valores são valores primitivos simples como strings, então isso não faz diferença. Mas se os valores são objetos / matrizes, etc, isso significa substituir esse objeto / matriz por outro novo objeto (em oposição a alterar seus valores internos). ( Exemplo de matriz , Exemplo de objeto )

Evite duplicar testes

É fácil copiar um caso de teste algumas vezes para testar variações ligeiramente diferentes da mesma coisa (por exemplo, {{#if foo}} começando com verdadeiro vs falso, ou a diferença entre um "POJO" vs um Ember.Object ), e fizemos muito isso nos testes existentes.

Às vezes, é o melhor que você pode fazer, mas há muitos problemas com isso. Primeiro, ele produz uma grande quantidade de testes fisicamente no arquivo, tornando difícil encontrar coisas. Além disso, quando alguém precisa adicionar um novo teste, geralmente escolhe aleatoriamente uma das poucas variantes, carregando detalhes / erros que não fazem muito sentido para o novo cenário. Quando consertarmos bugs em uma das cópias, provavelmente esqueceremos o resto.

Normalmente, existem maneiras de evitar a duplicação. Por exemplo, no caso de testar as diferentes condições iniciais ( {{#if foo}} contra true e false ), você pode apenas testar ambas as condições iniciais no mesmo teste:

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

Em outros casos, conseguimos definir comportamentos compartilhados extraindo algumas superclasses compartilhadas (colocando os casos de teste reais na superclasse) e configurando as partes que são diferentes na subclasse. Isso permite que você escreva os casos de teste uma vez e faça com que eles executem automaticamente muitos cenários diferentes (os testes de "Estilo de matriz").

O melhor exemplo é provavelmente o teste condicional ( if , unless , etc). O arquivo de teste real simplesmente define o estilo de invocação do modelo e a subclasse TogglingSyntaxConditionalsTest (localizada em shared-conditional-tests.js ) e obtém automaticamente muitos testes compartilhados.

Os testes "inline if / menos" levam isso ainda mais longe, executando o mesmo conjunto de casos de teste em 11 (!) Cenários de chamada diferentes.

A estrutura real de compartilhamento foi um tanto difícil de se chegar e levou algum tempo para amadurecer / acertar, mas a recompensa lá foi enorme (os cenários básicos agora são compartilhados entre {{#with}} e {{#each}} também).

Semântica legada

Muitos dos testes existentes usam semântica legada como views, {{view.foo}} , {{#view}} , context , controladores, etc. Na maioria das vezes, isso é puramente acidental e apenas um resultado do teste sendo escrito em uma época em que esses primitivos eram a principal forma de fazer as coisas. Nesses casos, você geralmente pode transferi-los para o novo chicote (que usa componentes) sem problemas.

Na dúvida, você também pode fazer um teste não portado na primeira iteração de seu PR e fazer suas perguntas em um comentário de linha.

Para attrs ou não para attrs

Decidimos não usar {{attrs.foo}} padrão em testes que usam componentes curvos (que são quase todos) e, em vez disso, confiar apenas nos atributos refletidos na propriedade com o mesmo nome (ou seja, apenas {{foo}} ). A menos que o teste seja especificamente _about_ testando attrs.* (aqueles provavelmente devem estar todos no mesmo arquivo), você geralmente deve preferir {{foo}} ao invés de {{attrs.foo}} para consistência. Você sempre pode nomear coisas como innerFoo vs outerFoo se sentir necessidade de eliminar a ambigüidade.

Veja também https://locks.svbtle.com/to-attrs-or-not-to-attrs por @locks.

Ressalvas

Às vezes, os testes que você transferiu podem não funcionar no Glimmer 2 ou HTMLBars. (Se não funcionar em nenhum dos motores, provavelmente você fez algo errado.)

No caso de não funcionar no Glimmer 2, provavelmente é porque ainda não implementamos esse recurso completamente. (Por exemplo, implementamos suporte a componentes básicos, mas não implementamos attributeBindings neste momento.)

Nesse caso, ainda é bom portar o teste para o novo estilo, para que possamos simplesmente ativá-lo quando o recurso for implementado. Para desabilitar um teste temporariamente para o Glimmer 2, você pode simplesmente substituir o prefixo @test no nome do método por @htmlbars (que significa "execute isto apenas em HTMLBars"). Você também pode desabilitar um módulo inteiro prefixando seu moduleFor name com @htmlbars .

Em alguns casos raros, o teste funcionará corretamente no Glimmer 2, mas não passa nas HTMLBars. Você deve verificar se a semântica que está testando está correta, mas também é bem possível que haja simplesmente um bug na implementação atual de HTMLBars. (Isso geralmente acontece quando testamos alguns recursos de HTMLBars com o novo "estilo de matriz", onde os valores não são atualizados corretamente em alguns casos extremos.)

Nesse caso, você pode sinalizar de forma semelhante um caso de teste individual ou um módulo inteiro como @glimmer . Uma vez que se espera que isso seja muito raro (e pode exigir uma correção de bug), seria útil se você pudesse incluir uma breve descrição dos problemas encontrados em um comentário de linha.

Exemplos

Aqui estão alguns dos excelentes exemplos em que os membros da nossa comunidade ajudaram a portar os testes existentes:

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

Como você pode ver, as iterações anteriores foram mais difíceis (ainda estávamos descobrindo a história dos casos de teste compartilhados), mas as últimas tentativas foram relativamente diretas. Obrigado @GavinJoyce e @chadhietala por

Então ... por onde eu começo?

Aqui está uma lista de bons pontos de partida. Se você está realmente decidido a trabalhar em um deles, provavelmente deixará um comentário abaixo para que outras pessoas saibam que não deve trabalhar nele. (Se você ficou sem tempo ou encontrou muita dificuldade, volte para "liberar o bloqueio" e / ou empurrar seu trabalho WIP, para que outras pessoas possam pegá-lo!)

• [x] Testes de renderização de conteúdo básico # 13141 por @chancancode

Não sei se isso já existe. Tente localizá-lo e portá-lo, se for o caso. Caso contrário, crie um novo arquivo para ele (já iniciamos algo em https://github.com/emberjs/ember.js/blob/master/packages/ember-glimmer/tests/integration/content-test.js) . A ideia é testar "o que acontece se você colocar algo estranho no DOM", por exemplo, {{foo}} , onde foo é undefined , null , e objeto, etc. Este é um alvo principal para o teste "Estilo de Matriz", então você pode querer estudar como o equipamento de teste funciona e extrair ideias dos testes condicionais.

Isso também deve absorver 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: por @chancancode e @ wycats)

Gostaríamos de examinar mais de perto esses testes e entender os requisitos. Bloqueando por agora.

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

Anunciamos que encerraremos o suporte para os complementos legados em 2.6, portanto, não precisaremos oferecer suporte a esses recursos no Glimmer 2. Abra os PRs para remover os testes e os recursos do master. (Isso provavelmente exigiria um conhecimento relativamente profundo da base de código.)

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

Esta pasta não é usada. Envie um PR para removê-lo.

• Ajudantes (acho que devemos movê-los para tests/integration/helpers )
  
  
  
  • [] [ -html-safe ] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/-html-safe-test.js): bloqueio :
  
  

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: por @ 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): tesouras: # 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] [testes auxiliares personalizados] (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): tesouras: # 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] [testes se / menos] (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: 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

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 -seta

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 e @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 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) (: lock: 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 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: 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).

• Testes de "integração"
  
  
  
  • [x] [testes de "associação 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] [testes de "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] [testes de "integração de ligação"] (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] [testes 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] [testes de invocação de componente] (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] [testes de ciclo de vida do componente] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/component_lifecycle_test.js) (: lock: por @chancancode e @ wycats)

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

• [x] [testes 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] [teste "helper lookup"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): tesoura: # 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] [ teste] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/input_test.js) (: lock: 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] [teste de "pesquisa local"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/helper-lookup-test.js): tesouras:

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

• [x] [teste de "ligação mutável"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/mutable_binding_test.js): bloqueio:

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): tesouras: # 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] [teste de "visualizações sem tag"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/tagless_views_rerender_test.js): tesouras: # 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] [teste do "elemento void"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/void-element-component-test.js): tesoura: # 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] [teste "willDestroyElement"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/helpers/will-destroy-element-hook-test.js) (: lock: 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] ["with + view" tests] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/integration/with_view_test.js): tesouras: # 13149 por @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>

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

A implementação de ViewNodManager provavelmente precisa ficar um pouco mais, porque algumas coisas internas ainda são implementadas como visualizações em htmlbars, mas isso não parece estar testando nada importante, então podemos provavelmente: tesoura: isto? @rwjblue você pode confirmar?

• Testes de "sistema"
  
  
  
  • [x] ["anexar visualização com modelo"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/append-templated-view-test.js): tesoura: # 13148 por @chadhietala
  
  

This is likely legacy. Please do investigate!

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

• [] [testes de "auxiliar de pesquisa"] (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] [testes de "render env"] (https://github.com/emberjs/ember.js/blob/master/packages/ember-htmlbars/tests/system/render_env_test.js): tesoura:: bloqueio: 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?

Provavelmente, há outros testes que precisam ser portados também. Se você notou algo que eu perdi, por favor mencione nos comentários.

Avaliações

Assim que estiver pronto para enviar seu PR (sinta-se à vontade para enviar PRs WIP!), Mencione esse problema na descrição de seu PR, para que possamos analisá-lo.

Prazo

Queremos que o maior número de testes seja portado o mais rápido possível. Idealmente, gostaríamos de ter a maioria (se não todos) dos testes portados dentro de uma ou duas semanas.

Agradeço antecipadamente por sua ajuda! : heart:: yellow_heart:: green_heart:: blue_heart:: purple_heart: