streamalism.org

1. Oversigt

Kodedækning er en softwaremetrik, der bruges til at måle, hvor mange linjer i vores kode der udføres under automatiserede tests.

I denne artikel vil vi gå gennem nogle praktiske aspekter af brugen JaCoCo - en generator for kodedækningsrapporter til Java-projekter.

2. Maven-konfiguration

For at komme i gang med JaCoCo er vi nødt til at erklære dette maven-plugin i vores pom.xml fil:

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

Linket, der er angivet her før, fører dig altid til den nyeste version af pluginet i det centrale lagringssted.

3. Rapporter om kodedækning

Før vi begynder at se på JaCoCos kodedækningsfunktioner, skal vi have en kodeeksempel. Her er en simpel Java-funktion, der kontrollerer, om en streng læser det samme baglæns og fremad:

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

Alt, hvad vi har brug for nu, er et simpelt JUnit prøve:

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

Når du kører testen ved hjælp af JUnit, sættes JaCoCo-agenten i gang automatisk, således at den opretter en dækningsrapport i binært format i målmappen - mål / jacoco.exec.

Vi kan åbenbart ikke fortolke output alene, men andre værktøjer og plugins kan - f.eks. Ekkolod Qube.

Den gode nyhed er, at vi kan bruge jacoco: rapport mål for at generere læsbare kodedækningsrapporter i flere formater - f.eks. HTML, CSV og XML.

Vi kan nu se for eksempel på target / site / jacoco / index.html side for at se, hvordan den genererede rapport ser ud:

Efter linket i rapporten - Palindrome.java , kan vi gennemgå en mere detaljeret visning for hver Java-klasse:

Bemærk, at du direkte kan administrere kodedækning ved hjælp af JaCoCo inde i Eclipse med nul konfigurationtak til EclEmma Eclipse-plugin.

4. Rapportanalyse

Vores rapport viser 21% instruktionsdækning, 17% filialdækning, 3/5 for cyklomatisk kompleksitet og så videre.

De 38 instruktioner, som JaCoCo viser i rapporten, henviser til instruktioner til bytekode i modsætning til almindelige Java-kodeinstruktioner.

JaCoCo-rapporter hjælper dig med visuelt at analysere kodedækning ved hjælp af diamanter med farver til grene og baggrundsfarver til linjer:

• Rød diamant betyder, at der ikke er udøvet grene i testfasen.
• Gul diamant viser, at koden delvis er dækket - nogle filialer er ikke udøvet.
• Grøn diamant betyder, at alle grene er blevet udøvet under testen.

Den samme farvekode gælder for baggrundsfarven, men for liniedækning.

JaCoCo giver primært tre vigtige metrics:

• Linjedækning afspejler den mængde kode, der er udøvet, baseret på antallet af Java-byte-kodeinstruktioner, der kaldes af testene.
• Grene dækning viser procentdelen af ​​udøvede filialer i koden - typisk relateret til hvis ellers og kontakt udsagn.
• Cyklomatisk kompleksitet afspejler kompleksitet af kode ved at angive antallet af stier, der er nødvendige for at dække alle de mulige stier i en kode gennem lineær kombination.

For at tage et trivielt eksempel, hvis der ikke er nogen hvis eller kontakt udsagn i koden, vil den cyklomatiske kompleksitet være 1, da vi kun har brug for en eksekveringssti til at dække hele koden.

Generelt afspejler den cyklomatiske kompleksitet antallet af testtilfælde, vi skal implementere for at dække hele koden.

5. Fordeling af koncept

JaCoCo kører som en Java-agent, det er ansvarlig for instrumentering af bytecode mens du kører testene. JaCoCo borer ind i hver instruktion og viser, hvilke linjer der udøves under hver test.

For at indsamle dækningsdata bruger JaCoCo ASM til kodeinstrumentering i farten og modtager begivenheder fra JVM-værktøjsgrænseflade i processen:

Det er også muligt at køre JaCoCo-agenten i servertilstand. I dette tilfælde kan vi køre vores tests med jacoco: dump som et mål at starte en dumpanmodning.

Du kan følge det officielle dokumentationslink for mere detaljerede detaljer om JaCoCo-design.

6. Kodedækning score

Nu hvor vi ved lidt om, hvordan JaCoCo fungerer, lad os forbedre vores kode dækning score.

For at opnå 100% kodedækning er vi nødt til at indføre tests, der dækker de manglende dele vist i den oprindelige rapport:

@Test offentligt ugyldigt nårPalindrom_thenAccept () {Palindrome palindromeTester = new Palindrome (); assertTrue (palindromeTester.isPalindrome ("middag")); } @Test offentlig ugyldig nårNearPalindrom_thanReject () {Palindrome palindromeTester = new Palindrome (); assertFalse (palindromeTester.isPalindrome ("neon")); }

Nu kan vi sige, at vi har nok test til at dække hele koden, men for at sikre os det, lad os køre kommandoen Maven mvn jacoco: rapport at offentliggøre dækningsrapporten:

Som du kan se, er alle linjer / grene / stier i vores kode fuldt dækket:

I det virkelige verdensprojekt, og når udviklingen går videre, er vi nødt til at holde styr på kodedækningsscore.

JaCoCo tilbyder en enkel måde at erklære på minimumskrav der skal være opfyldt, ellers mislykkes bygningen.

Det kan vi gøre ved at tilføje følgende kontrollere mål i vores pom.xml fil:

 jacoco-check check PACKAGE LINE COVEREDRATIO 0,50 

Som du sikkert kan gætte, begrænser vi her minimumscore for liniedækning til 50%.

Det jacoco: check Målet er bundet til verificere, så vi kan køre kommandoen Maven - mvn ren kontrol for at kontrollere, om reglerne overholdes eller ej. Logfilerne viser noget som:

[FEJL] Kunne ikke udføre mål org.jacoco: jacoco-maven-plugin: 0.7.7.201606060606: check (jacoco-check) ved projektmutationstest: Dækningskontrol er ikke opfyldt.

7. Konklusion

I denne artikel har vi set, hvordan man bruger JaCoCo maven-plugin til at generere kodedækningsrapporter til Java-projekter.

Husk dog, 100% kodedækning afspejler ikke nødvendigt, hvilket afspejler effektiv test, da det kun afspejler den mængde kode, der udøves under test. I en tidligere artikel har vi talt om mutationstest som en mere sofistikeret måde at spore testets effektivitet i forhold til almindelig kode dækning.

Du kan tjekke eksemplet i denne artikel i det linkede GitHub-projekt.