La copertura del codice migliora la qualità del codice? [duplicare]

Suppongo che tu stia facendo riferimento a una metrica Copertura del codice nel contesto dei test unitari. Se è così, penso che tu abbia già indirettamente risposto alla tua domanda qui:

First project just used targeted unit tests here and there. Second one has a mandated 70% code coverage. If I compare the amount of defects, the 2nd one has almost an order of magnitude more of them.

In breve no, una metrica di copertura del codice non migliora affatto la qualità di un progetto.

C'è anche la credenza comune che la copertura del codice rifletta la qualità dei test unitari, ma non lo fa. Non ti fornisce alcuna informazione su quali parti del tuo sistema sono state testate correttamente. Dice solo quale codice è stato eseguito dalla tua suite di test. Quello che sai per certo è che la copertura del codice ti fornisce solo informazioni su quali parti del tuo sistema non sono state testate.

Tuttavia, la metrica della copertura del codice può riguardare la qualità generale del codice se si è certi della qualità dei test delle unità. La qualità di un test unitario può essere definita come la capacità di essere in grado di rilevare un cambiamento nel codice base che rompe alcuni requisiti aziendali. In altre parole, ogni cambiamento che rompe un particolare requisito (criterio di accettazione) dovrebbe essere rilevato da test di buona qualità (tali test dovrebbero semplicemente fallire). Uno dei più semplici e automatizzati approcci per misurare la qualità della tua suite di test che non comporta un ulteriore sforzo aggiuntivo da parte tua è test di mutazione .

UPDATE:

link

La copertura del codice ti dice quanto del tuo codice è coperto dai test. Non ti dice molto sulla qualità dei test. Ad esempio, una copertura del codice di, diciamo, il 70% potrebbe essere ottenuta da test automatici che esercitano funzionalità banali come getter e setter e tralasciare cose più importanti come verificare che un calcolo complesso fornisca risultati corretti, casi angolari e così via. Anche se la copertura del codice è al 100%, i test potrebbero non considerare input speciali per il codice che causano il fallimento. Quindi, una copertura del codice relativamente alta non implica necessariamente che il codice sia ben testato e quindi i difetti non possono ancora essere rilevati dai test.

D'altra parte, una copertura di codice basso significa che gran parte del codice non è stato testato affatto , quindi può essere che alcuni moduli importanti non siano correttamente verificati. A volte ha senso avere una copertura del codice relativamente bassa per i test automatici, ad es. può essere più efficace fare clic su un pulsante GUI e verificare che venga visualizzata la finestra di dialogo appropriata (test manuale) piuttosto che scrivere un test automatico corrispondente. Tuttavia, anche in questo scenario la copertura combinata per i test automatici e manuali sarebbe alta.

Quindi, la copertura del codice IMO solo non è un buon indicatore della qualità dei test perché funziona solo in una direzione:

1. un punteggio di copertura del codice basso può indicare correttamente il codice che non è stato testato e potrebbe essere bacato o persino codice guasto;
2. un alto punteggio di copertura del codice può nascondere i test scadenti e può darti troppa fiducia nella qualità del tuo codice.

Nota

Grazie a GNAT per avermi indicato per la copertura del codice per i test manuali.

Come reductio at absurdum : il seguente test copre il 60% delle linee della funzione:

def abs(x):
    if x < 0:
        return -x
    else:
        return x

assertEquals(abs(-10), 10)

mentre in questo esempio, abbiamo una copertura del 100%:

def abs(x):
    if x < 0:
        return -x

assertEquals(abs(-10), 10)

Naturalmente, solo quest'ultimo ha un bug.

La copertura del codice può essere d'aiuto, ma da sola non è un buon indicatore.
Dove può aiutare è che costringe le persone a lavorare coscientemente con il codice per scrivere i test che forniscono tale copertura, e questo è probabile che causi loro di vedere potenziali problemi e risolverli.

Ma se le persone che fanno questo non sono realmente interessate al codice, possono solo costruire meccanicamente un codice di test che copra tutto senza preoccuparsi di pensare a cosa effettivamente fa il codice e se è corretto.

Di conseguenza può portare a un falso senso di sicurezza. Ma se il team è adeguatamente motivato e interessato a fornire qualità è un buon modo per aiutare un team a trovare aree del codice sospette e che devono essere esaminate per potenziali problemi.

E il solo conteggio delle righe coperte non è sufficiente per questo, hai bisogno anche della copertura delle filiali, ad esempio, testando i diversi percorsi attraverso dichiarazioni condizionali o tutti i possibili risultati.

Il requisito di copertura del codice del 70% è stato inserito prima che i programmatori non scrivessero i test unitari? Se è così, mi aspetto che il risultato dipenda più dall'atteggiamento dei programmatori sul progetto piuttosto che dalla regola di copertura del codice del 70%?

La copertura del codice è un buon strumento per aiutare con i test unitari di targeting, ma solo quando viene utilizzata da persone che credono nel beneficio dei test unitari e sono abili nello scrivere test unitari.

No. La copertura del codice non migliora la qualità del codice.

Semplice, la copertura del codice ti dice quanto la tua linea di codice è stata eseguita nei metodi di test.
Non ti sta dicendo che il risultato del tuo codice di produzione è stato affermato o meno.

Penso che questo non possa darti informazioni sulla qualità del codice di produzione.

Se scrivi codice in stile TDD, non hai affatto bisogno della copertura del codice. Scrivi già solo il codice coperto da test scritti prima.