Rapporti di copertura del codice separati per test unitari e di integrazione o un rapporto per entrambi?

Dovrebbe esserci un rapporto sulla copertura del codice separato per i test unitari e di integrazione o un rapporto sulla copertura del codice per entrambi?

L'idea alla base di ciò è che la copertura del codice ci consente di assicurarci che il nostro codice sia stato coperto da test per quanto possibile (il più possibile una macchina ora).

Avere un rapporto separato è più conveniente per noi sapere cosa non è stato coperto dai test unitari e cosa non è stato coperto dai test di integrazione. Ma in questo modo non possiamo vedere la percentuale di copertura totale.

Soprattutto, è necessario disporre e analizzare la copertura (totale) combinata. Se ci pensate, questo è il modo più naturale per stabilire correttamente le priorità dei rischi e focalizzare le attività di sviluppo dei test.

Copertura combinata mostra cosa codice non è coperto da test a tutti , vale a dire è più rischioso e bisogno di essere indagato prima. Rapporti di copertura separati non ti aiuteranno qui, in quanto non ti consentono di scoprire se il codice è testato in qualche altro modo o non testato affatto.

Anche un'analisi della copertura separata può essere utile, ma sarebbe meglio farlo dopo aver terminato l' analisi combinata e preferibilmente coinvolgerebbe anche i risultati dell'analisi della copertura combinata.

Lo scopo dell'analisi della copertura separata differisce da quello combinato. L'analisi della copertura separata aiuta a migliorare la progettazione della suite di test, al contrario dell'analisi della copertura combinata che ha lo scopo di decidere i test da sviluppare, qualunque cosa accada.

"Oh, questo divario non è coperto solo perché ci siamo dimenticati di aggiungere quel semplice test unitario (integrazione) nella nostra suite unitaria (integrazione), aggiungiamolo" - la copertura e l'analisi separate sono più utili qui, dal momento che una combinazione potrebbe nascondere delle lacune che vorresti coprire in una particolare suite.

Dal punto di vista di cui sopra, è comunque desiderabile avere anche risultati di analisi di copertura combinate al fine di analizzare casi più complicati. Pensaci, con questi risultati, le tue decisioni di sviluppo dei test potrebbero essere più efficienti a causa della disponibilità di informazioni sulle suite di test "partner".

"C'è un vuoto qui, ma lo sviluppo di un test unitario (di integrazione) per coprirlo sarebbe davvero ingombrante, quali sono le nostre opzioni? Controlliamo la copertura combinata ... oh, è già coperta altrove, cioè coprirla nella nostra suite non è ' di fondamentale importanza. "

Non menzioni il tuo strumento di test. Molti hanno funzioni "combinate" che consentono di aggregare i risultati di più esecuzioni o suite. Se desideri una metrica di copertura aggregata, esplora la funzione di combinazione nello strumento di copertura.

Ora, possiamo parlare dell'elefante nella stanza?

Non c'è il cucchiaio. E non esiste una "percentuale di copertura totale". Almeno nessuno semplice.

La percentuale di copertura è una metrica di facile comprensione presentata per aiutare a comprendere l'ambito, la profondità e la gamma delle suite di test. Ma come ogni semplice benchmark, è molto facile diventare target fissati su questo valore come una sorta di talismano magico di "test completi".

Supponiamo che tu abbia raggiunto la gloria della "copertura del test al 100%". Sìì! Ma cosa significa? Il 100% delle righe di codice viene testato, giusto? E che dire di questa linea?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

"Coprire" quella linea significa qualcosa - ma non molto, perché ci sono una varietà di condizioni che sono Trueo Falsecon qualche probabilità, ma è improbabile che tu abbia testato tutte le combinazioni di quelle condizioni. Anche se quella linea è coperta una dozzina di volte, se una delle condizioni è relativamente rara, non ti sei avvicinato al test di tutti i risultati reali che potrebbero verificarsi nella pratica. Per renderlo più chiaro, un esempio più sintetico:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

Quante volte dovresti coprire quella linea per testarla in modo esaustivo? Quante volte dovresti coprirlo per testarlo in combinazione con tutte le altre variabili del programma (con le loro probabilità, possibilmente similmente rare)?

Non sto dicendo che le metriche di copertura siano inutili. In realtà sono fantastici . Si concentrano su uno dei problemi chiave: quanto è ampiamente testato il mio sistema software? Aiutano a passare da "abbiamo alcuni test" a "abbiamo testato a fondo".

Ma mentre stai lavorando su "punteggi combinati", la realtà è che il tuo punteggio sarà in genere per "copertura delle dichiarazioni" piuttosto che per "condizione", "predicato" o "percorso" . Quindi, qualunque sia il numero che ti danno i punteggi aggregati, è improbabile che ti dia un quadro reale di quanti stati potenziali del tuo programma e combinazioni di stati vengono testati. Mentre lavori per aumentare la percentuale di copertura, considera anche la misurazione della copertura del predicato. Ti fornirà una visione più realistica - e quasi invariabilmente, più rassicurante - dell'estensione del test.