Un team segnala con orgoglio una copertura del codice del 95%, quindi invia un bug in una riga che è stata “coperta”. Questa non è una contraddizione. La copertura risponde a una domanda ristretta: i test hanno eseguito questo codice? Se abbiano controllato il risultato è una questione completamente diversa.

Abbiamo utilizzato Python con cover.py 7.17 e pytest 9.2. Ogni numero e rapporto riportato di seguito proviene dalla nostra corsa. Le idee si applicano in qualsiasi lingua.

Cos’è la copertura del codice?

La copertura del codice è la percentuale del codice che viene eseguito durante l’esecuzione dei test automatizzati. Uno strumento registra quali righe e, facoltativamente, quali rami sono stati eseguiti, quindi segnala cosa è stato mancato.

È molto utile al contrario. Una bassa copertura in un’area ti dice, con certezza, che i test non la stanno esercitando. Una copertura elevata dice molto meno.

Tipi di copertura

Ogni livello è più severo di quello superiore. La maggior parte dei team monitora la copertura di linee e filiali. La copertura delle condizioni e MC/DC compaiono negli standard aeronautici e automobilistici, dove il supporto degli utensili è specializzato.

Il codice che abbiamo misurato

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

Il nostro primo file di test aveva due test:

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

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

L’abbiamo eseguito con la misurazione del ramo attivata:

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

Leggendo il rapporto

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

• Stmts 9, Miss 1: nove istruzioni eseguibili, una mai eseguita.
• Ramo 6, BrParte 1: tre if decisioni danno sei possibili risultati. Una decisione è andata sempre e solo in una direzione.
• Missing 3: riga 3, la raise ValueError, non è mai stata eseguita. Nessun test ha superato un totale negativo.

La correzione è un test per il percorso dell’errore. Abbiamo anche aggiunto un test per un ordine di grandi dimensioni:

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

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

Con entrambi i file, il rapporto mostrava il 100% e nessuna riga mancante o ramo parziale. I percorsi di errore sono i classici ritrovamenti di copertura dei gap, motivo per cui i test per input non validi, progettati con tecniche come il partizionamento di equivalenza, si accoppiano così bene con esso.

Cosa nascondeva il rapporto

Guarda di nuovo il primo rapporto. Diceva che mancava solo la linea 3. Ma i primi due test ne hanno utilizzati entrambi un totale di 500, quindi la regola di spedizione gratuita per ordini pari o superiori a 1.000 è stata mai testata e il rapporto non l’ha segnalata.

Il motivo è che fee = 0 if total >= 1000 else 50 si trova su una riga. cover.py misura i rami tra le righe, quindi un’espressione condizionale all’interno di una singola riga conta come un’istruzione eseguita. Se quella regola avesse un bug, come > invece di >=, la prima suite avrebbe comunque mostrato l’87% senza alcun suggerimento. I test del confine stesso, come descritto in analisi del valore limite, sono ciò che lo rileva.

Copertura al 100% senza controlli

Successivamente, abbiamo scritto un test deliberatamente scadente che richiama ogni percorso ma non asserisce nulla:

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%

Ha raggiunto il 100% di copertura di linee e filiali. La funzione potrebbe restituire qualsiasi numero e il test verrebbe comunque superato. Questo è il limite fondamentale della copertura: misura l’esecuzione, non la verifica.

Per misurare se i test rilevano effettivamente i bug, utilizzare il test di mutazione. Uno strumento come mutmut per Python, PIT per Java o Stryker per JavaScript apporta piccole modifiche al codice, come capovolgere da >= a >, e controlla che un test fallisca. Il nostro test di non asserzione consentirebbe la sopravvivenza di ogni mutazione.

Quale obiettivo fissare

Non esiste un numero universalmente corretto. Guida pratica:

• Non inseguire il 100%. L’ultima percentuale spesso significa testare codice banale o scrivere test che toccano solo le righe.
• Molti team puntano a circa il 70-85% in totale, con aspettative più elevate per la logica del core business.
• Osserva la tendenza, non il numero. La copertura che diminuisce a ogni pubblicazione è un segnale di avvertimento.
• Richiedere la copertura del nuovo codice nelle richieste pull anziché forzare il vecchio codice tutto in una volta.
• Escludi ciò che non conta, come il codice generato, con regole chiare.

Si applica la legge di Goodhart: quando una misura diventa un obiettivo, smette di essere una buona misura. Gli obiettivi difficili incoraggiano test come il nostro esempio di non asserzione.

Strumenti per lingua

Copertura in CI

Esegui la copertura come parte della tua pipeline CI e pubblica il rapporto in modo che i revisori possano vedere quali nuove righe non sono state testate. Con cover.py, coverage report --fail-under=80 fallisce la compilazione al di sotto di una soglia. Mantieni qualsiasi soglia modesta e combinala con una regola sul nuovo codice, in modo che un unico file legacy di grandi dimensioni non blocchi ogni modifica.

Oltre la copertura: domande migliori da porre

• I test coprono le parti del codice rischiose e frequentemente modificate?
• Vengono messi alla prova i confini e i percorsi di errore, non solo il percorso felice?
• Un test fallirebbe se questa riga fosse sbagliata?
• I test sono sufficientemente veloci e stabili da poter essere eseguiti ad ogni modifica?

Questi appartengono a qualsiasi strategia di test. La copertura aiuta a rispondere solo alla prima.

Esclusione del codice e lettura dei report HTML

Non vale la pena testare direttamente alcuni codici, come gli helper di debug o un blocco che viene eseguito solo quando uno script viene avviato manualmente. cover.py ti consente di escludere le righe con un commento:

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

Puoi anche impostare le esclusioni e le cartelle di origine da misurare nella configurazione, ad esempio in pyproject.toml:

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

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

Utilizza le esclusioni con parsimonia e rivedile come codice. Ognuna è una decisione secondo cui alcune linee non verranno mai controllate. Escludere un gestore di errori difficile da testare solo per aumentare il numero vanifica lo scopo.

Per il lavoro quotidiano il report HTML è più utile della tabella terminale. Esegui coverage html e apri htmlcov/index.html. Ogni file viene mostrato con le linee eseguite in verde, le linee mancate in rosso e i rami parziali in giallo, così puoi vedere a colpo d’occhio quale if non ha mai preso l’altra strada. Molti editor possono anche mostrare la copertura a margine, rendendo visibili gli spazi vuoti mentre si scrive il codice anziché dopo.

Copertura prima del refactoring

La copertura è anche un controllo di sicurezza prima del refactoring. Se intendi ristrutturare un modulo, guarda prima il suo rapporto. Le aree rosse non hanno test per avvisarti se il comportamento cambia, quindi aggiungi test di caratterizzazione che catturano il comportamento attuale prima di iniziare. Utilizzata in questo modo, la copertura smette di essere un obiettivo e diventa uno strumento pratico di pianificazione.

Lo stesso report aiuta quando un bug sfugge alla produzione. Trova la riga in cui risiedeva il bug e controlla se qualche test lo ha eseguito. In caso contrario, hai trovato una lacuna che vale la pena colmare. Se un test lo ha eseguito, il problema è un’asserzione debole, che è esattamente la situazione mostrata dal nostro esempio senza asserzione. Entrambe le risposte ti dicono come migliorare la suite.

Considerazioni finali

La copertura del codice è una torcia, non un voto. Utilizzare la copertura delle filiali per trovare codice che nessun test tocca, in particolare la gestione degli errori, e quindi scrivere test che facciano asserzioni reali. Se ricordi un risultato della nostra analisi, dillo questo: la copertura del 100% è stata raggiunta da un test che non ha verificato nulla.

Domande frequenti

Continua a imparare