Introduksjon til JaCoCo

1. Oversikt

Kodedekning er en programvare beregning som brukes til å måle hvor mange linjer i koden vår blir utført under automatiserte tester.

I denne artikkelen skal vi spasere gjennom noen praktiske aspekter ved bruk JaCoCo - en kodedekning rapporterer generator for Java-prosjekter.

2. Maven-konfigurasjon

For å komme i gang med JaCoCo, må vi erklære dette maven-pluginet i vårt pom.xml fil:

 org.jacoco jacoco-maven-plugin 0.7.7.201606060606 forbered agentrapport forbered pakke rapport 

Koblingen som er gitt her før, fører deg alltid til den nyeste versjonen av programtillegget i Maven Central Repository.

3. Kodedekningsrapporter

Før vi begynner å se på JaCoCos kodedekningsfunksjoner, må vi ha et kodeeksempel. Her er en enkel Java-funksjon som sjekker om en streng leser det samme bakover og fremover:

public boolean isPalindrome (String inputString) {if (inputString.length () == 0) {return true; } annet {char firstChar = inputString.charAt (0); char lastChar = inputString.charAt (inputString.length () - 1); Streng midt = inputString.substring (1, inputString.length () - 1); retur (firstChar == lastChar) && isPalindrome (mid); }}

Alt vi trenger nå er enkelt JUnit test:

@Test offentlig ugyldig nårEmptyString_thenAccept () {Palindrome palindromeTester = new Palindrome (); assertTrue (palindromeTester.isPalindrome ("")); }

Å kjøre testen ved hjelp av JUnit vil automatisk sette i gang JaCoCo-agenten, og dermed opprette en dekningsrapport i binært format i målkatalogen - mål / jacoco.exec.

Åpenbart kan vi ikke tolke utdataene på egenhånd, men andre verktøy og plugins kan - f.eks. Ekkolodd Qube.

Den gode nyheten er at vi kan bruke jacoco: rapport mål for å generere lesbare kodedekningsrapporter i flere formater - f.eks. HTML, CSV og XML.

Vi kan nå se for eksempel på mål / nettsted / jacoco / index.html side for å se hvordan den genererte rapporten ser ut:

Etter lenken i rapporten - Palindrome.java , kan vi gå gjennom en mer detaljert visning for hver Java-klasse:

Merk at du enkelt kan administrere kodedekning ved hjelp av JaCoCo inne i Eclipse med null konfigurasjon, takket være EclEmma Eclipse-plugin.

4. Rapportanalyse

Rapporten vår viser 21% instruksjonsdekning, 17% filialdekning, 3/5 for syklomatisk kompleksitet og så videre.

De 38 instruksjonene som JaCoCo viser i rapporten viser til instruksjoner for bytekode i motsetning til vanlige Java-kodeinstruksjoner.

JaCoCo-rapporter hjelper deg visuelt å analysere kodedekning ved å bruke diamanter med farger for grener og bakgrunnsfarger for linjer:

  • Rød diamant betyr at ingen grener har blitt utøvd i testfasen.
  • Gul diamant viser at koden er delvis dekket - noen filialer har ikke blitt utøvd.
  • Grønn diamant betyr at alle grener har blitt utøvd under testen.

Den samme fargekoden gjelder bakgrunnsfargen, men for linjedekning.

JaCoCo gir hovedsakelig tre viktige beregninger:

  • Linjedekning gjenspeiler mengden kode som har blitt utøvd basert på antall Java-byte-kodeinstruksjoner som kalles av testene.
  • Grener dekning viser prosentandelen av utøvde grener i koden - vanligvis relatert til hvis / annet og bytte om uttalelser.
  • Syklomatisk kompleksitet gjenspeiler kompleksiteten til koden ved å gi antall stier som trengs for å dekke alle mulige stier i en kode gjennom lineær kombinasjon.

For å ta et trivielt eksempel, hvis det ikke er noe hvis eller bytte om uttalelser i koden, vil den syklomatiske kompleksiteten være 1, ettersom vi bare trenger en kjøringsbane for å dekke hele koden.

Generelt reflekterer den syklomatiske kompleksiteten antall testsaker vi trenger å implementere for å dekke hele koden.

5. Konseptfordeling

JaCoCo kjører som en Java-agent, det er ansvarlig for instrumentere bytekoden mens du kjører testene. JaCoCo borer inn i hver instruksjon og viser hvilke linjer som utøves under hver test.

For å samle dekningsdata bruker JaCoCo ASM for kodeinstrumentering på farta, mottar hendelser fra JVM-verktøygrensesnitt i prosessen:

Det er også mulig å kjøre JaCoCo-agenten i servermodus. I dette tilfellet kan vi kjøre testene våre med jacoco: dump som et mål, å starte en dumpeforespørsel.

Du kan følge den offisielle dokumentasjonskoblingen for mer inngående detaljer om JaCoCo-design.

6. Kodedekning

Nå som vi vet litt om hvordan JaCoCo fungerer, la oss forbedre poengsummen for kodedekning.

For å oppnå 100% kodedekning må vi innføre tester som dekker de manglende delene som vises i den første rapporten:

@Test offentlig ugyldig nårPalindrom_thenAccept () {Palindrome palindromeTester = new Palindrome (); assertTrue (palindromeTester.isPalindrome ("noon")); } @Test offentlig ugyldig nårNærPalindrom_thanReject () {Palindrome palindromeTester = new Palindrome (); assertFalse (palindromeTester.isPalindrome ("neon")); }

Nå kan vi si at vi har nok tester for å dekke hele koden, men for å sikre oss det, la oss kjøre Maven-kommandoen mvn jacoco: rapport for å publisere dekningsrapporten:

Som du kan se er alle linjer / grener / stier i koden vår fullstendig dekket:

I det virkelige verdensprosjektet, og når utviklingen går lenger, må vi holde oversikt over kodedekningspoengene.

JaCoCo tilbyr en enkel måte å erklære på minstekrav som skal oppfylles, ellers mislykkes bygningen.

Vi kan gjøre det ved å legge til følgende Sjekk mål i vårt pom.xml fil:

 jacoco-sjekk sjekk PAKKELINJE DEKKER 0.50 

Som du sikkert kan gjette begrenser vi her minimumspoengsummen for linjedekning til 50%.

De jacoco: sjekk målet er bundet til bekrefte, slik at vi kan kjøre Maven-kommandoen - mvn ren bekreft for å sjekke om reglene blir respektert eller ikke. Loggene viser noe sånt som:

[FEIL] Kunne ikke utføre mål org.jacoco: jacoco-maven-plugin: 0.7.7.201606060606: sjekk (jacoco-sjekk) på prosjektmutasjonstesting: Dekningskontroll er ikke oppfylt.

7. Konklusjon

I denne artikkelen har vi sett hvordan du kan bruke JaCoCo maven-plugin for å generere kodedekningsrapporter for Java-prosjekter.

Husk imidlertid 100% kodedekning gjenspeiler ikke effektiv testing, da det bare gjenspeiler mengden kode som utøves under tester. I en tidligere artikkel har vi snakket om mutasjonstesting som en mer sofistikert måte å spore testens effektivitet i forhold til vanlig kodedekning.

Du kan sjekke ut eksemplet i denne artikkelen i lenken GitHub-prosjekt.


$config[zx-auto] not found$config[zx-overlay] not found