Si sta ottenendo l'errore relativo a classID. Questo è un concetto descritto in dettaglio nel sito di JaCoCo docs. http://www.eclemma.org/jacoco/trunk/doc/classids.html. Questo è un passo fondamentale per supportare più versioni di classe (un server delle applicazioni per esempio) nella stessa JVM.
Copia parte di esso qui per visibilità.
Quali sono gli ID di classe e come vengono creati?
ID di classe sono valori interi a 64 bit, ad esempio in 0x638e104737889183 notazione esadecimale. Il loro calcolo è considerato un dettaglio di implementazione di JaCoCo. Attualmente gli ID vengono creati con un checksum CRC64 del file di classe non elaborato.
Cosa può causare ID di classe diversi?
ID di classe sono identici per lo stesso file di classe solo (byte per byte). Ci sono un paio di motivi per cui potresti ottenere diversi file di classe. Prima compilazione file sorgente Java si tradurrà nei file di classe diverse se si utilizza un diverso tool chain:
diverso compilatore fornitore (ad esempio Eclipse vs Oracle JDK)
versioni del compilatore diverse
diverse impostazioni del compilatore (ad esempio, eseguire il debug vs non-debug)
Anche i file di classe di post-elaborazione (offuscamento, AspectJ, ecc.) Modificano in genere i file di classe. JaCoCo funzionerà bene se usi semplicemente gli stessi file di classe per runtime e per analisi. Quindi la catena di strumenti per creare questi file di classe non ha importanza.
Anche se i file di classe sul file system sono gli stessi, è possibile che le classi viste dall'agente di runtime JaCoCo siano diverse comunque. Ciò accade in genere quando un altro agente Java viene configurato prima che l'agente JaCoCo oi caricatori di classi speciali pre-elaborino i file di classe.candidati tipici sono:
- quadri beffardo
- I server di applicazioni
- Persistenza quadri
La stessa pagina copre le possibili soluzioni.
Quali soluzioni alternative esistono per gestire le classi modificate in runtime?
Se le classi vengono modificati in fase di esecuzione nella configurazione ci sono alcune soluzioni per rendere JaCoCo lavorare in ogni modo:
- Se si utilizza un altro agente Java assicurarsi che l'agente JaCoCo è specificato in un primo momento nella riga di comando. In questo modo l'agente JaCoCo dovrebbe vedere i file di classe originali.
- Specificare l'opzione classdumpdir dell'agent JaCoCo e utilizzare le classi dumped alla generazione del report. Tieni presente che verranno scaricate solo le classi caricate, ovvero le classi non eseguite affatto non verranno visualizzate nel tuo rapporto come non coperte.
- Utilizza la strumentazione offline prima di eseguire i test. In questo modo le classi vengono strumentate da JaCoCo prima che qualsiasi modifica del runtime possa avvenire. Si noti che in questo caso il report deve essere generato con le classi originali, non con quelle strumentate.
Redatta il 22-02-2017
Come usare Offline Strumentazione: Usa sotto compito fornito da Daniel Atallah.
//Additional SourceSets can be added to the jacocoOfflineSourceSets as needed by
project.ext.jacocoOfflineSourceSets = [ 'main' ]
task doJacocoOfflineInstrumentation(dependsOn: [ classes, project.configurations.jacocoAnt ]) {
inputs.files classes.outputs.files
File outputDir = new File(project.buildDir, 'instrumentedClasses')
outputs.dir outputDir
doFirst {
project.delete(outputDir)
ant.taskdef(
resource: 'org/jacoco/ant/antlib.xml',
classpath: project.configurations.jacocoAnt.asPath,
uri: 'jacoco'
)
def instrumented = false
jacocoOfflineSourceSets.each { sourceSetName ->
if (file(sourceSets[sourceSetName].output.classesDir).exists()) {
def instrumentedClassedDir = "${outputDir}/${sourceSetName}"
ant.'jacoco:instrument'(destdir: instrumentedClassedDir) {
fileset(dir: sourceSets[sourceSetName].output.classesDir, includes: '**/*.class')
}
//Replace the classes dir in the test classpath with the instrumented one
sourceSets.test.runtimeClasspath -= files(sourceSets[sourceSetName].output.classesDir)
sourceSets.test.runtimeClasspath += files(instrumentedClassedDir)
instrumented = true
}
}
if (instrumented) {
//Disable class verification based on https://github.com/jayway/powermock/issues/375
test.jvmArgs += '-noverify'
}
}
}
test.dependsOn doJacocoOfflineInstrumentation
Ora generare report utilizzando il comando "gradlew test jacocoTestReport".
Aggiungi come viene generato executiondata ('$ {jacocoexec.filename}')? Ci dovrebbe essere un bersaglio separato che esegua il compito 'jacoco: coverage'. Metti questo obiettivo alla domanda pure. –
aggiungendo il parametro -javaagent durante l'esecuzione del test case: -javaagent: JaCoCoProject/lib/jacocoagent.jar = destfile = JaCoCoProject/jacoco.exec, output = file – anon
si prega di condividere il file di build completo. Tutto quello che l'errore sta dicendo è che hai strumentato un barattolo, hai eseguito test. Quelle classi non provengono da "./jar/abc.jar". Non è sufficiente abbinare le classi per nome. devono corrispondere al "classID" visto da jacoco- il che significa che anche se ricompilate, le classi sono diverse. – Jayan