Een team rapporteert trots dat de code voor 95% bedekt is, en verzendt vervolgens een bug in een regel die “gedekt” was. Dit is geen tegenstrijdigheid. De dekking beantwoordt één beperkte vraag: hebben de tests deze code uitgevoerd? Of ze het resultaat hebben gecontroleerd, is een heel andere vraag.

We gebruikten Python met dekking.py 7.17 en pytest 9.2. Elk nummer en rapport hieronder is uit onze eigen run. De ideeën zijn in elke taal toepasbaar.

Wat is codedekking?

Codedekking is het percentage van uw code dat wordt uitgevoerd terwijl uw geautomatiseerde tests worden uitgevoerd. Een tool registreert welke lijnen, en eventueel welke vertakkingen, zijn uitgevoerd en rapporteert vervolgens wat er is gemist.

Het is het nuttigst in omgekeerde richting. Een lage dekking in een gebied vertelt u met zekerheid dat er geen tests zijn uitgevoerd. Een hoge dekking zegt veel minder.

Soorten dekking

Elk niveau is strenger dan het niveau erboven. De meeste teams houden de lijn- en aftakkingsdekking bij. Conditiedekking en MC/DC komen voor in luchtvaart- en automobielnormen, waar gereedschapsondersteuning gespecialiseerd is.

De code die we hebben gemeten

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

Ons eerste testbestand kende twee tests:

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

We hebben het uitgevoerd met de takmeting ingeschakeld:

coverage run --branch -m pytest test_shipping.py
coverage report -m

Het rapport lezen

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9, Miss 1: negen uitvoerbare instructies, waarvan er één nooit is uitgevoerd.
• Tak 6, BrDeel 1: drie if beslissingen geven zes mogelijke uitkomsten. Eén beslissing ging maar één kant op.
• Ontbrekende 3: regel 3, de raise ValueError, is nooit uitgevoerd. Geen enkele test heeft een negatief totaal behaald.

De oplossing is een test voor het foutpad. Voor een grote bestelling hebben we ook een test toegevoegd:

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

Bij beide bestanden toonde het rapport 100% en geen ontbrekende regels of gedeeltelijke vertakkingen. Foutpaden zijn de klassieke ontdekkingen van gap-dekking. Daarom passen tests voor ongeldige invoer, ontworpen met technieken als equivalentiepartitionering, er zo goed bij.

Wat het rapport verborgen hield

Kijk nog eens naar het eerste rapport. Er stond dat alleen lijn 3 ontbrak. Maar bij de eerste twee tests werden er beide een totaal van 500 gebruikt, dus de regel voor gratis verzending voor bestellingen van 1000 of meer werd nooit getest, en het rapport vermeldde dit niet.

De reden is dat fee = 0 if total >= 1000 else 50 op één regel staat. dekking.py meet vertakkingen tussen regels, dus een voorwaardelijke expressie binnen een enkele regel telt als één uitgevoerde instructie. Als die regel een bug zou bevatten, zoals > in plaats van >=, zou de eerste suite nog steeds 87% hebben weergegeven zonder enige hint. Het testen van de grens zelf, zoals beschreven in grenswaardeanalyse, is wat deze vastlegt.

100% dekking zonder controles

Vervolgens hebben we een opzettelijk slechte test geschreven die elk pad oproept maar niets beweert:

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

De dekking bereikte 100% lijn- en filiaaldekking. De functie kan elk willekeurig getal retourneren en deze test zou nog steeds slagen. Dit is de kernlimiet van de dekking: het meet de uitvoering, niet de verificatie.

Als je wilt meten of tests daadwerkelijk bugs ontdekken, gebruik je mutatietests. Een tool als mutmut voor Python, PIT voor Java of Stryker voor JavaScript brengt kleine wijzigingen in je code aan, zoals het omdraaien van >= naar >, en controleert of een test mislukt. Onze no-asss-test zou ervoor zorgen dat elke mutatie overleeft.

Welk doel te stellen

Er bestaat geen universeel correct getal. Praktische begeleiding:

• Ga niet voor de volle 100%. De laatste paar procent betekent vaak het testen van triviale code of het schrijven van tests die slechts één lijn bevatten.
• Veel teams streven naar een totaalpercentage van grofweg 70 tot 85%, met hogere verwachtingen ten aanzien van de kernbedrijfslogica.
• Let op de trend, niet op het aantal. De berichtgeving die bij elke release afneemt, is een waarschuwingssignaal.
• Vereist dekking van nieuwe code in pull-verzoeken in plaats van oude code in één keer te forceren.
• Sluit uit wat er niet toe doet, zoals gegenereerde code, met duidelijke regels.

De wet van Goodhart is van toepassing: wanneer een maatregel een doelwit wordt, is deze niet langer een goede maatregel. Harde doelen moedigen tests aan, zoals ons voorbeeld zonder assertiviteit.

Hulpmiddelen per taal

Dekking in CI

Voer dekking uit als onderdeel van uw CI-pijplijn en publiceer het rapport zodat reviewers kunnen zien welke nieuwe regels nog niet zijn getest. Met dekking.py mislukt coverage report --fail-under=80 de build onder een drempel. Houd elke drempel bescheiden en combineer deze met een regel over nieuwe code, zodat één groot verouderd bestand niet elke wijziging blokkeert.

Naast dekking: betere vragen om te stellen

• Bestrijken tests de risicovolle, vaak gewijzigde delen van de code?
• Worden grenzen en foutenpaden getest, en niet alleen het gelukkige pad?
• Zou een test mislukken als deze regel verkeerd was?
• Zijn de tests snel en stabiel genoeg om bij elke wijziging uit te voeren?

Deze horen thuis in elke teststrategie. Dekking helpt alleen bij het beantwoorden van de eerste vraag.

Exclusief code en lezen van HTML-rapporten

Sommige code is het niet waard om direct te testen, zoals debug-helpers of een blok dat alleen wordt uitgevoerd als een script met de hand wordt gestart. Met dekking.py kunt u regels uitsluiten met een opmerking:

if __name__ == "__main__":  # pragma: no cover
    main()

U kunt ook uitsluitingen en de te meten bronmappen instellen in de configuratie, bijvoorbeeld in pyproject.toml:

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

Wees spaarzaam met uitsluitingen en bekijk ze als code. Elk ervan is een beslissing dat sommige regels nooit zullen worden gecontroleerd. Het uitsluiten van een moeilijk te testen foutafhandelaar alleen maar om het aantal op te heffen, schiet het doel voorbij.

Voor het dagelijkse werk is het HTML-rapport nuttiger dan de terminaltabel. Voer coverage html uit en open htmlcov/index.html. Elk bestand wordt weergegeven met uitgevoerde regels in het groen, gemiste regels in rood en gedeeltelijke vertakkingen in geel, zodat je in één oogopslag kunt zien welke if nooit een andere weg is ingeslagen. Veel redacteuren kunnen ook dekking in de marge weergeven, waardoor hiaten zichtbaar worden tijdens het schrijven van de code in plaats van achteraf.

Dekking vóór refactoring

Dekking is ook een veiligheidscontrole vóór refactoring. Als u van plan bent een module te herstructureren, bekijk dan eerst het rapport ervan. Rode gebieden hebben geen tests om u te waarschuwen als gedrag verandert, dus voeg karakteriseringstests toe die het huidige gedrag vastleggen voordat u begint. Op deze manier is dekking niet langer een doelwit, maar wordt het een praktisch planningsinstrument.

Hetzelfde rapport helpt wanneer een bug naar de productie ontsnapt. Zoek de regel waar de bug zich bevond en controleer of deze door een test is uitgevoerd. Zo niet, dan heb je een gat gevonden dat de moeite waard is om te dichten. Als een test dit wel heeft uitgevoerd, is het probleem een ​​zwakke bewering, en dat is precies de situatie die ons voorbeeld zonder bewering liet zien. Beide antwoorden vertellen u hoe u de suite kunt verbeteren.

Tot slot

Codedekking is een zaklamp, geen cijfer. Gebruik branchedekking om code te vinden die geen enkele test raakt, vooral de foutafhandeling, en schrijf vervolgens tests die echte beweringen doen. Als u zich één resultaat van onze run herinnert, laat het dan dit zijn: 100% dekking werd bereikt door een test die niets controleerde.

Veelgestelde vragen

Blijf leren