Come gestisci la misurazione della copertura del codice in JavaScript

Question

Come gestisci la misurazione della copertura del codice in JavaScript

#1 da (3 voti)
#2 da (0 voti)

5

Per misurare la copertura del codice per i test delle unità JavaScript, è necessario strumentare il codice, eseguire i test e quindi eseguire la post-elaborazione.

La mia preoccupazione è che, di conseguenza, tu sia un codice di test unitario che non verrà mai eseguito in produzione. Poiché JavaScript non è compilato, ciò che si prova dovrebbe essere esattamente ciò che si esegue.

Quindi ecco la mia domanda, come gestisci questo? Un pensiero che ho avuto è stato quello di eseguire Unit Testing sul codice di produzione e usarlo per il mio passaggio fallito. Creo quindi un'ombra del mio codice di produzione, con la strumentazione e eseguo di nuovo i miei test unitari; questo mi darebbe le mie statistiche sulla copertura del codice.

Qualcuno ha incontrato un metodo un po 'più elegante di questo?

Modifica Non voglio utilizzare i plug-in del browser, perché è necessario utilizzare un browser per eseguire i miei test di unità.

unit-testing javascript test-coverage

posta Dancrumb 27.06.2012 - 22:34

fonte

2 risposte

Leggi altre domande sui tag unit-testing javascript test-coverage

Differenza tra setter a molla e iniezione interfaccia? Strumenti Javascript per copertura filiali [chiuso]

score 3 · Answer 1

Leggi questo in strumenti di copertura del codice per JavaScript , che ha alcuni collegamenti, anche se la maggior parte sono in effetti le estensioni del browser.

Tuttavia, considera JsTestDriver , che ha supporto per la copertura del codice e consente di eseguire test al di fuori del browser connettendosi con un altro strumento di test (come HtmlUnit ).

score 0 · Answer 2

Non sono anti-test, ma il concetto stesso di provare a stabilire "copertura del codice" nel JavaScript sul lato client mi sembra un punto in cui mi manca il punto. Non risolvere problemi che non hai. Preoccupati dei rischi reali, non di tutti i codici che hai scritto. I rischi nel mio libro sono il codice che entra in contatto con cose di terze parti su cui non si ha il controllo o una parte di un'app malamente architettata in cui troppe mani si trovano nello stesso barattolo di biscotti. Se un'intera app è fragile e soggetta a problemi di regressione, tutto ciò che cerca di ottenere la massima copertura del codice fa per te più codice cattivo.

L'esecuzione di codice in JS lato client è banale. Dovresti testare tutto ciò che fai accuratamente mentre lo scrivi e mantenere le cose pulite e disaccoppiate per evitare errori di regressione in primo luogo.