Cosa dovrebbe essere testato in Javascript?

Al lavoro, abbiamo appena iniziato su un'applicazione fortemente basata su Javascript (in realtà usando Coffeescript, ma ancora), di cui ho implementato un sistema di test automatizzato usando JsTestDriver e fabric.

Non abbiamo mai scritto qualcosa con così tanto Javascript, quindi fino ad ora non abbiamo mai fatto alcun test Javascript. Non sono sicuro di cosa dovremmo testare esattamente nei nostri test unitari. Abbiamo scritto plugin JQuery per varie cose, quindi è abbastanza ovvio che dovrebbero essere verificati il più possibile per correttezza con JsTestDriver, ma tutti gli altri membri del mio team sembrano pensare che dovremmo testare anche Javascript a livello di pagina.

Non credo che dovremmo testare Javascript a livello di pagina come unit test, ma invece utilizzare un sistema come Selenium per verificare che tutto funzioni come previsto. Il mio ragionamento principale per questo è che al momento, i test Javascript a livello di pagina hanno esito negativo tramite JsTestDriver, perché stanno cercando di accedere a elementi sul DOM che non possono esistere.

Quindi, cosa dovrebbe essere testato in unità in Javascript?

javascript testing unit-testing

— Nathan Hoad
fonte

Isoli qualsiasi codice javascript che hai scritto nei moduli. Quindi è sufficiente testare gli ingressi e le uscite di tali moduli. Qualsiasi modulo che si occupa del DOM significa che devi testare il DOM. Usa uno strumento migliore di jsTestDriver.

— Raynos,

Dovresti testare la logica di business unit. Se la tua logica aziendale e gli elementi sul DOM sono intrecciati, allora hai un difetto di progettazione. Estrarre quanta più logica di business possibile dagli elementi della pagina in modo che possa essere adeguatamente testato dall'unità. Per la verifica dell'interazione dell'elemento DOM dovresti usare Selenium.

— maple_shaft

@NathanHoad Scrivi unit test che vengono eseguiti nel browser stesso, nodeunit, qunit e jasmine sono strumenti sensati. Durante l'esecuzione nel browser hai il DOM. È possibile utilizzare uno strumento come il testling per automatizzare i test del browser.

— Raynos,

Grazie. Stavo guardando verso jsTestDriver poiché sosteneva di essere in grado di funzionare nel browser, che, sebbene tecnicamente vero, ho scoperto che non è lo stesso di correre con QUnit. Al momento sto lavorando sul mio strumento che utilizza QUnit, con un pannello della barra degli strumenti di debug Django personalizzato. Usando il selenio sarò in grado di rilevare i test falliti. Inoltre, dubito che il mio capo pagherebbe per il test, anche se sembra abbastanza buono!

— Nathan Hoad,

correlate: Come testate il vostro javascript

— gnat

Risposte:

Metti alla prova tutto ciò che puoi.

La logica pura può essere testata facilmente.

Se il tuo codice interagisce con il DOM o la rete, è molto più difficile.

Se riesci a sottrarre un pezzo di codice per lavorare su un elemento DOM arbitrario anziché su uno specifico, puoi testarlo più facilmente. (Fai in modo che l'elemento funzioni su un parametro).

Il codice che utilizza Ajax può essere testato semplicemente chiamando la funzione di callback con dati fissi. Ho avuto alcuni test in cui ho sovrascritto $.ajaxcon la mia funzione. Assicurati di rimettere quello vero quando hai finito!

Quello che troverete è che "javascript a livello di pagina" significa davvero "codice strettamente accoppiato" e se si disaccoppiano le parti del codice, è possibile testarle indipendentemente.

(Il selenio non è uno strumento di test unitario. È ottimo per scenari di alto livello, ma non è possibile testarlo con esso e non funziona in un ambiente isolato.)

— Sean McMillan
fonte

jasmine può prendere in giro chiamate di funzione e dati di risposta, si potrebbe esaminare quello invece di sovrascrivere le funzioni.

— Steve,

Dovrei chiarire - abbiamo funzioni e simili su ogni pagina. Stavo parlando di più sul test del codice che viene eseguito all'interno $(document).ready(...).

— Nathan Hoad,

È tutta una questione di quanto sia grande .... :-) Sento che dovresti essere in grado di farlo scendere a una singola funzione denominata che è anche testata. Quindi il tuo codice non testato è una riga singola. (Ora questo è un obiettivo, non un dato. In pratica ho sempre avuto più di una riga di codice non testato.)

— Sean McMillan,

@SeanMcMillan - Trovo molto difficile testare parti di un'applicazione che interessano solo il DOM, ad esempio, una funzione che lega solo diversi eventi ad alcuni elementi DOM. Come verifichi che quegli eventi siano stati scritti correttamente? non è qualcosa che i test unitari possono fare, ma il clic e il controllo del browser reale (usando il selenio o qualsiasi altra cosa)

— vsync

@vsync: puoi provare che, per esempio, un gestore di clic è stato collegato abbastanza facilmente a un determinato elemento DOM. Non credo sia possibile verificare che il "clic" sia il gestore giusto e che tu l'abbia collegato all'elemento giusto.

— Sean McMillan,

Algoritmi di test. Le parti strettamente correlate alla GUI dipendono maggiormente dal browser specifico, quindi devono essere testate utilizzando utility simili al selenio.

Il tuo codice, ovviamente, deve contenere algoritmi come un pezzo di codice isolato, se non lo è allora il test unitario è quasi impossibile.

i plugin jquery, a proposito, non sono facili da testare sull'unità.

— Sergey Stolyarov
fonte

Tutti i punti positivi! Sono d'accordo che non sono facilmente testabili anche in unità, a seconda di come sono scritti.

— Nathan Hoad,

-1

Lavoravo con Java e da quello che vedo test di unità Java è più semplice del test di unità JavaScript perché Java è più rigido.

Sono venduto su quello sviluppo test-driven è la cosa migliore, quindi sto anche esplorando come test unit unit JavaScript. In Java ho deriso il codice che stabiliva la connessione al database, gli oggetti di accesso ai dati e lo confronto con il codice in JavaScript che modifica il DOM e il codice che effettua le chiamate AJAX al server.

Quello che sto arrivando è che mi sembra che ciò che dovrebbe essere testato sia esplicitamente la logica. Ad esempio, non si desidera effettuare una chiamata AJAX quando si eseguono test di unità perché (a) è necessario che il server sia in esecuzione e (b) sia lento e una delle linee guida del test di unità è che deve essere super veloce in modo che gli sviluppatori non evitino di eseguirli come ogni minuto.

Un'altra linea guida è per il processo di integrazione continua di inviare una e-mail dicendo che ha trovato un test unit che non è riuscito.

— SBEL
fonte