Encontrei este tópico sobre testes de plugins (automaticamente), mas não encontrei nenhuma menção sobre como testar temas ou componentes de tema. Existem exemplos de como usar QUnit (ou algo similar) com temas?
Você pode adicioná-lo a um tema selecionável pelo usuário ou usar o link de teste na página de administração do tema.
Desculpe, eu quis dizer testes automatizados – vou corrigir minha postagem anterior. Eu estava pensando em algo como QUnit, que alguns plugins já utilizam.
Não, atualmente não é possível adicionar testes QUnit a temas/componentes…
@david, quão viável seria adicionar suporte a uma pasta /test como nos plugins? Também teríamos que habilitar o tema durante a execução dos testes, já que os testes do núcleo são executados sem nenhum tema, certo?
Definitivamente possível, mas precisará de algum trabalho. No momento, todos os arquivos JavaScript do tema estão agrupados em um único arquivo. Precisaremos garantir que os testes sejam colocados em um novo pacote separado, para que não sejam entregues aos visitantes comuns. E, uma vez feito isso, criar uma maneira de executar os testes QUnit para um único tema.
Outra coisa a considerar é que não disponibilizamos a rota /qunit nos servidores de produção. Como os temas são frequentemente desenvolvidos em servidores de produção, talvez precisemos repensar isso ![]()
Essa é, na minha opinião, uma das principais desvantagens dos componentes de tema. Eles são super fáceis de implantar, o que é fantástico, mas os testes muitas vezes ficam de lado.
Se entendi corretamente, tudo o que pode ser feito com um componente de tema também pode ser feito com um plugin. O primeiro é mais fácil de implantar, enquanto o segundo permite testes.
Sim, isso é geralmente preciso. Acaba sendo uma troca em termos do que você está personalizando. Por exemplo, adicionar uma folha de estilos personalizada provavelmente não poderia ser testada nem mesmo em um plugin. É ao adicionar controles e widgets personalizados em JavaScript que as coisas se tornam questionáveis.
Sinto que devemos considerar essa questão ao trabalharmos no ember cli. Não há nada impossível em ter algum tipo de test runner para temas, e poderíamos incluir alguns recursos básicos no gem discourse-theme para configurar testes locais usando o ember cli.
Executar testes de tema exigiria, no entanto, uma instalação completa do Discourse, certo? Existem tantas interdependências que acho que não poderíamos testar os temas de forma independente ![]()
Talvez o theme-cli pudesse ter alguma lógica para puxar a imagem docker do discourse_dev e executar os testes qunit dentro dela?
A ideia por trás do ember cli é separar claramente o servidor do cliente. Poderíamos distribuir o suficiente do lado do JavaScript para testar o cliente sem precisar rodar um servidor Rails. Você ainda precisaria ter o node e o ember cli instalados, com certeza, mas talvez consiga evitar a instalação de uma pilha completa do Discourse, incluindo Redis e Postgres.
Pode ser complicado, mas é algo que definitivamente podemos ter em mente.
Agora suportamos testes em temas (atualização tardia, o suporte para testes de temas foi adicionado em meados de 2021). Você pode acessar /theme-qunit em seu ambiente local ou em seu site de produção, e quaisquer temas/componentes instalados que tenham testes serão listados lá. Veja Discourse Tab Bar for Mobile ou Componente de ícones de tags para exemplos.
Isso é ótimo. Isso se estenderá aos testes de javascript em plugins?
Você quer dizer poder executar testes em produção? Isso é apenas para temas no momento.
(Localmente, você pode executar testes de JS de plugins, é claro.)
Acho que o objetivo seria ser capaz de executá-los no CI no GitHub, como atualmente podemos fazer com as especificações (tanto JavaScript de Tema quanto de Plugin)?
Sim, executamos testes no CI para todos os plugins oficiais.