2015-03-02 8 views
36

Ho configurato Karma per segnalare la copertura del mio codice JavaScript. Ecco la parte della configurazione nel file karma.conf.js:Come modificare il formato del report LCOV eseguito da Karma?

coverageReporter: { 
    reporters: [ 
    { 
     type: 'html', 
     dir: 'build/karma/coverage' 
    }, 
    { 
     type: 'lcov', 
     dir: 'build/karma/coverage', 
     subdir: '.' 
    }, 
    { 
     type: 'cobertura', 
     dir: 'build/karma/coverage' 
    } 
    ] 
}, 

Il mio file lcov.info ha il seguente formato:

TN: 
SF:./app/scripts/app.js 
FN:16,(anonymous_1) 
FN:26,(anonymous_2) 
FNF:2 
FNH:1 
FNDA:1,(anonymous_1) 
FNDA:0,(anonymous_2) 
DA:2,1 
DA:20,1 
DA:29,0 
DA:34,0 
LF:4 
LH:2 
BRF:0 
BRH:0 
end_of_record 

Purtroppo, the Sonarqube JavaScript plugin considera solo le righe che iniziano con SF:, DA: o BRDA: (cf LCOVParser).

A causa di ciò, il report HTML LCOV (realizzato da Istanbul) mi fornisce una copertura del codice più elevata rispetto a Sonar sugli stessi dati.

C'è un modo per modificare il formato dello lcov.info generato?


Se guardo in Istanbul code, posso immaginare il significato delle diverse etichette:

  • BRF, BRH, BRDA sono per rami.
  • FN, FNF, FNH, FNDA sono per funzioni.
  • LN, LF, LH sono per righe.
  • *F è il totale, mentre *H è l'informazione coperta.

La differenza tra la copertura di Istanbul e Sonar sembra essere dovuta al fatto che quest'ultimo ignora completamente la copertura di funzioni e rami.

Qualche idea per risolverlo?

+0

Hai pensato di usare il karma-sonarqube-unit-giornalista: https://www.npmjs.com/package/karma-sonarqube-unit-reporter – DevDig

+0

Corremmo anche in questo e poi abbandonato il plugin javascript per eseguire direttamente gli script. https://github.com/carsdotcom/gulp-sonar È un bel plugin per funzionare nel tuo gulpfile. Potrebbe non funzionare per tutte le situazioni, ma ha risolto questo problema per noi. – devilfart

+0

Abbiamo avuto un problema simile in cui il sonar si aspettava un percorso di file assoluto per calcolare la copertura. La nostra soluzione alternativa era di aggiungere un'attività di compilazione che modificava lcov.info per aggiungere il prefisso del percorso assoluto su SF: linee – claya

risposta

2

È possibile eseguire uno script che: cat lcov.info | egrep "^(SF|DA|BRDA):" > lcov.info.new; mv lcov.info.new lcov.info.

Con che ottengo:

SF:./app/scripts/app.js 
DA:2,1 
DA:20,1 
DA:29,0 
DA:34,0 
Problemi correlati