Non aver paura di Chrome senza testa! Scopri perché e come utilizzarlo per i test di Ember

Ultimo aggiornamento 01/09/17, Ember CLI 2.15. Un ringraziamento speciale a Scott Newcomer e Ben Demboski per l'aiuto nel debug, Karl Becker per il montaggio e Tobias Bieniek per alcuni suggerimenti sulla CLI!

Dopo alcune ore il debug della mia suite di test EmberJS che si è rifiutata di eseguire dalla riga di comando, ho abbandonato PhantomJS e sono passato a Headless Chrome. Analizziamo cosa significa tutto, come l'ho fatto e quali sono gli impatti.

Che cos'è anche Headless Chrome?

Gli sviluppatori di Ember hanno opzioni per i quali browser utilizzano per eseguire la suite di test e Chrome senza testa è uno di questi. Ma cos'è? Il blog di Google dice:

È un modo per eseguire il browser Chrome in un ambiente senza testa. In sostanza, eseguire Chrome senza Chrome!
(Alt: cos'è questo, non ho nemmeno ...)

Destra. Ecco una definizione migliore da Wikipedia:

Un browser senza testa è un browser web senza un'interfaccia utente grafica. I browser senza testa forniscono il controllo automatico di una pagina Web in un ambiente simile ai browser Web più diffusi, ma vengono eseguiti tramite un'interfaccia della riga di comando o tramite la comunicazione di rete.

A partire da Ember CLI 2.15, Chrome senza testa è l'impostazione predefinita per i test in EmberJS. Se stai lavorando con un'app Ember precedente, ho buone notizie: non è necessario aggiornare l'app per provare Chrome senza testa. È un dato di fatto, è possibile utilizzare l'ultima versione della CLI con quasi tutte le versioni precedenti dell'app Ember.

Perché è necessario un ambiente "senza testa"?

Proprio come un normale browser, un browser senza testa comprende HTML e CSS. Può eseguire JavaScript come richieste AJAX. Pensa ai test di accettazione in Ember. Se un test tenta di fare clic su un pulsante nascosto, non dovrebbe essere selezionabile e il test dovrebbe fallire. Ma come si sa? Perché il browser fa il duro lavoro di combinare tutto HTML, CSS e JavaScript in qualcosa di utile. E poiché non ci sono immagini da visualizzare, i test sono più veloci in un ambiente senza testa. Esistono molti tipi diversi di browser senza testa. Chrome e PhantomJS sono solo due esempi.

Quindi, perché non eseguire semplicemente i test direttamente in un normale browser Chrome? Se hai un'app Ember, esegui ember serve e visita http: // localhost: 4200 / tests, puoi effettivamente guardare i tuoi test in esecuzione in tempo reale o metterli in pausa e osservare visivamente lo stato dell'app. Tuttavia, dove i browser senza testa brillano davvero è quando vengono utilizzati per i test di integrazione continua, comunemente denominati CI. Nelle app di produzione, è comune utilizzare un servizio che esegue automaticamente la suite di test quando viene eseguito il commit del codice. E per la maggior parte, quei test vengono eseguiti su un server, non su browser "normali". Ad esempio, controlla le richieste pull aperte per una parte del sito Web di Ember, in particolare quelle con una x rossa accanto a loro. Ogni volta che una richiesta pull viene aperta su GitHub, puoi vedere se supera i test.

Questa non è la mia richiesta pull. Lo giuro. (Alt: immagine che mostra più errori di test su una richiesta pull di GitHub)

Perché non usare PhantomJS?

PhantomJS è un altro esempio di browser senza testa. Creare e mantenere era un compito erculeo, e il suo successo è il motivo per cui abbiamo cose carine. Costruire app è difficile ... puoi immaginare di costruire un intero browser ??? Ma sembra che stia per uscire. Un manutentore si è dimesso nell'aprile 2017, dicendo:

Chrome senza testa sta arrivando. Penso che le persone passeranno ad esso, alla fine. Chrome è più veloce e più stabile di PhantomJS. E non mangia la memoria come un matto. Non vedo alcun futuro nello sviluppo di PhantomJS.

Come notato dal manutentore, PhantomJS ha alcuni problemi. Ne avevo uno mio: nessuno dei miei test avrebbe funzionato. Tutto andava bene in una nuova app, ma alcune parti sconosciute della mia vera app non erano compatibili dopo aver introdotto dipendenze consolidate. Ho eseguito il test della brace, ma prima ancora che iniziasse qualsiasi test, sono stato accolto con questi errori:

non ok 1 PhantomJS 2.1 - Errore globale: SintassiError: token imprevisto "}" su http: // localhost: 7357 / assets / vendor.js, linea 120177
non ok 2 PhantomJS 2.1 - Errore globale: errore: impossibile trovare il modulo ember-metal richiesto da: ember-testing / support su http: // localhost: 7357 / assets / test-support.js, linea 58
non ok 3 PhantomJS 2.1 - Errore globale: Errore di riferimento: Impossibile trovare la variabile: definire su http: // localhost: 7357 / assets / ember-bio-bright.js, linea 5
non ok 4 PhantomJS 2.1 - Errore globale: Errore di riferimento: Impossibile trovare la variabile: definire su http: // localhost: 7357 / assets / tests.js, linea 3
non ok 5 PhantomJS 2.1 - Errore globale: Errore di riferimento: Impossibile trovare la variabile: EmberENV su http: // localhost: 7357/4215 / tests / index.html? hidepassed, linea 38

Ho gettato tutto a questo errore. Far saltare in aria i moduli del nodo, rimuovere tutto tranne il test più semplice, reinstallare EmberCLI, installare / disinstallare PhantomJS, scavare nel bundle del fornitore, condividere GIF di gatti arrabbiati, accendere un po 'di incenso ... niente.

Dopo un po 'di domande e risposte con un paio di altri sviluppatori, mi è stato suggerito di provare Headless Chrome per vedere se gli errori sono diventati più facili da eseguire il debug.

Gli errori non sono diventati più facili da eseguire il debug.

Gli errori sono semplicemente scomparsi.

Come effettuare il passaggio

C'è un file nelle app di Ember chiamato testem.js, ed è qui che si configurano gli strumenti di test da usare quando si digita ember test o ember test —- server. Ecco un link al contenuto testem.js che ho finito per usare, copiato e incollato dall'articolo di Ryan Toronto. È possibile visualizzare il file testem fornito con EmberCLI a questo link su EmberCLI GitHub.

Che cos'è Testem?

Testem è un test runner, il che significa che carica ed esegue i test della tua app, utilizzando la configurazione specificata in testem.js. È inoltre disponibile un'interfaccia intuitiva per visualizzare i risultati dei test dalla riga di comando. Sono stato sorpreso di apprendere che Testem non è unico per Ember. Funziona con molti framework JavaScript, strumenti di test (come QUnit, Mocha e Jasmine) e ambienti browser.

Guarda questo? Questo è Testem in azione, derivante da `ember test - server`. Come puoi vedere, il mio ultimo lavoro su ember-api-docs sta andando benissimo. Andrà tutto bene e sicuramente so cosa sto facendo. Non. (Alt: finestra terminale in cui il testem runner mostra 175 errori di test)

Quali impatti negativi potrebbe avere Headless Chrome?

Bene, per prima cosa, Headless Chrome non è open source come PhantomJS. I pro ei contro potrebbero essere il loro articolo.

È anche nuovo. È stato fornito con Chrome 59, ma gli sviluppatori hanno già avuto modo di utilizzare Chrome. La grande domanda è, se stai già facendo i test CI, quanto bene lo supporta il tuo fornitore? Molti dei grandi giocatori sono stati rapidi nell'implementarlo, ma è possibile che si verifichino alcuni problemi.

Infine, potresti avere alcuni test che superano PhantomJS e falliscono in Headless Chrome, il che significa che è tempo di fare un po 'di debug. Certo, ho sperimentato il contrario, dove tutti i miei problemi sono scomparsi magicamente quando ho cambiato browser senza testa, ma i problemi non sono rari. Questo è un punto dolente simile alle cose che sembrano grandi in Chrome ma esplodono in Firefox. Per questo motivo e per rendere i test più solidi, alcune organizzazioni eseguono i test in più strumenti senza testa.

Quando passare

Se ti senti bloccato, o semplicemente vuoi sapere com'è l'ultimo e il più grande per i test di Ember, provalo!

Buon test senza testa!

Opere d'arte di IrenHorrors, condivise con licenza Creative Commons Attribution-Non commercial-No Derivative Works 3.0