Ho trovato questo topic sui test dei plugin (automatici), ma non ho mai visto menzionare come testare i temi o i componenti dei temi. Ci sono esempi su come usare QUnit (o qualcosa di simile) con i temi?
Puoi aggiungerlo a un tema selezionabile dallâutente o utilizzare il link di test nella pagina di amministrazione del tema.
Scusa, intendevo i test automatizzati â correggerò il mio post precedente. Stavo pensando a qualcosa come QUnit che alcuni plugin giĂ utilizzano.
No, al momento non è possibile aggiungere test QUnit a temi o componentiâŚ
@david, quanto sarebbe fattibile aggiungere il supporto per una cartella /test simile a quella dei plugin? Dovremmo anche abilitare il tema durante lâesecuzione dei test, dato che i test core vengono eseguiti senza alcun tema, giusto?
Certamente possibile, ma richiederĂ un poâ di lavoro. Al momento, tutti i file JavaScript del tema sono raggruppati in un unico file. Dovremmo assicurarci che i test vengano inseriti in un nuovo bundle separato, in modo che non vengano forniti ai visitatori ordinari. Una volta fatto ciò, bisognerĂ creare un modo per eseguire i test QUnit per un singolo tema.
Unâaltra cosa da considerare è che non rendiamo disponibile la rotta /qunit sui server di produzione. PoichĂŠ i temi vengono spesso sviluppati sui server di produzione, potremmo dover ripensare a questa impostazione ![]()
Questo è, a mio parere, uno dei principali svantaggi dei componenti del tema. Sono estremamente semplici da distribuire, il che è fantastico, ma i test vengono spesso trascurati.
Se ho capito correttamente, tutto ciò che può essere fatto con un componente del tema può essere fatto anche con un plugin. Il primo è piÚ semplice da distribuire, mentre il secondo consente i test.
SĂŹ, è generalmente corretto. Alla fine si tratta di un compromesso in base a ciò che si sta personalizzando. Ad esempio, lâaggiunta di un foglio di stile personalizzato probabilmente non potrebbe essere testata nemmeno in un plugin. Ă quando si aggiungono controlli e widget JavaScript personalizzati che le cose diventano problematiche.
Credo che dovremmo considerare questa problematica quando svolgeremo il lavoro su Ember CLI. Non câè nulla di impossibile nel creare una sorta di test runner per i temi, e potremmo includere alcune funzionalitĂ di base nel gem discourse-theme per impostare i test locali utilizzando Ember CLI.
Tuttavia, lâesecuzione dei test del tema richiederebbe unâinstallazione completa di Discourse, giusto? Ci sono cosĂŹ tante interdipendenze che non credo potremmo testare i temi in modo indipendente ![]()
Forse il theme-cli potrebbe avere una logica per scaricare lâimmagine Docker discourse_dev ed eseguire i test QUnit allâinterno di essa?
Lâidea alla base di Ember CLI è separare in modo pulito il server dal client. Potremmo fornire una parte sufficiente del lato JavaScript per testare il client senza dover eseguire un server Rails. Dovresti comunque avere installati Node e Ember CLI, ma potresti evitare di installare lâintera pila di Discourse, inclusi Redis e Postgres.
Potrebbe essere complicato, ma è sicuramente qualcosa da tenere a mente.
Ora supportiamo i test nei temi (aggiornamento tardivo, il supporto per i test dei temi è stato aggiunto a metà 2021). Puoi accedere a /theme-qunit nel tuo ambiente locale o nel tuo sito di produzione, e tutti i temi/componenti installati che hanno test saranno elencati lÏ. Vedi Discourse Tab Bar for Mobile o Componente icone tag per esempi.
Questo è fantastico. Si estenderà anche al testing di javascript nei Plugin?
Intendi la possibilità di eseguire test in produzione? Al momento è possibile solo per i temi.
(Ovviamente, a livello locale puoi eseguire i test JS dei plugin.)
Penso che lâobiettivo sarebbe poterli eseguire in CI su GitHub come possiamo attualmente fare con le specifiche (sia Theme. che Plugin JS)?
SĂŹ, eseguiamo test in CI per tutti i plugin ufficiali.