it-swarm-eu.dev

Qual è una percentuale di copertura del codice ragionevole per i test unitari (e perché)?

Se dovessi imporre una percentuale minima di copertura del codice per i test unitari, forse anche come requisito per il commit su un repository, quale sarebbe?

Per favore spiega come sei arrivato alla tua risposta (dal momento che se tutto ciò che hai fatto è stato scegliere un numero, allora avrei potuto farlo tutto da solo;)

557
sanity

Questa prosa di Alberto Savoia risponde proprio a questa domanda (in modo molto divertente!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus On Test Coverage

Una mattina presto, un programmatore ha chiesto al grande maestro:

"Sono pronto a scrivere alcuni test unitari. A che copertura del codice dovrei mirare? "

Il grande maestro rispose:

"Non preoccuparti della copertura, scrivi solo dei buoni test".

Il programmatore sorrise, si inchinò e se ne andò.

...

Più tardi quel giorno, un secondo programmatore fece la stessa domanda.

Il grande maestro indicò una pentola di acqua bollente e disse:

"Quanti chicchi di riso dovrei mettere in quella pentola?"

Il programmatore, guardando perplesso, rispose:

"Come posso dirtelo? Dipende da quante persone hai bisogno di nutrire, da quanto sono affamate, da quale altro cibo stai servendo, da quanto riso hai a disposizione e così via. "

"Esatto," disse il grande maestro.

Il secondo programmatore sorrise, si inchinò e se ne andò.

...

Verso la fine della giornata, un terzo programmatore è venuto e ha fatto la stessa domanda sulla copertura del codice.

"L'ottanta percento e non meno!" Rispose il maestro con voce severa, battendo il pugno sul tavolo.

Il terzo programmatore sorrise, si inchinò e se ne andò.

...

Dopo quest'ultima risposta, un giovane apprendista si avvicinò al grande maestro:

"Grande maestro, oggi ho sentito per caso rispondere alla stessa domanda sulla copertura del codice con tre risposte diverse. Perché?"

Il grande maestro si alzò dalla sua sedia:

"Vieni a prendere un tè fresco con me e parliamone."

Dopo aver riempito le loro tazze con il fumo del tè verde caldo, il grande maestro cominciò a rispondere:

"Il primo programmatore è nuovo e appena iniziato con i test. In questo momento ha un sacco di codice e nessun test. Ha una lunga strada da percorrere; concentrarsi sulla copertura del codice in questo momento sarebbe deprimente e abbastanza inutile. Sta meglio solo abituarsi a scrivere e fare alcuni test. Può preoccuparsi della copertura più tardi. "

"Il secondo programmatore, d'altra parte, è abbastanza esperto sia in fase di programmazione che di test. Quando ho risposto chiedendole quanti chicchi di riso dovrei mettere in una pentola, l'ho aiutata a capire che la quantità di test necessari dipende da una serie di fattori, e lei conosce questi fattori meglio di me: è il suo codice dopo tutto . Non c'è una risposta semplice, semplice, ed è abbastanza intelligente da gestire la verità e lavorare con quello. "

"Capisco," disse il giovane apprendista, "ma se non c'è una sola risposta semplice, allora perché hai risposto al terzo programmatore" L'ottanta percento e non meno "?"

Il grande maestro scoppiò a ridere così forte e forte che la sua pancia, la prova che beveva più del tè verde, si alzò e si abbassò.

"Il terzo programmatore vuole solo risposte semplici - anche quando non ci sono risposte semplici ... e poi non le segue comunque."

Il giovane apprendista e il grande maestro brizzolato finirono di bere il loro tè in silenzio contemplativo.

1269
Jon Limjap

La copertura del codice è una metrica fuorviante se il tuo obiettivo è il 100% di copertura (anziché il 100% di test di tutte le funzionalità).

  • Potresti ottenere il 100% colpendo tutte le linee una volta. Tuttavia potresti ancora perdere l'occasione di testare una particolare sequenza (percorso logico) in cui vengono colpite quelle linee.
  • Non è stato possibile ottenere il 100% ma sono stati comunque testati tutti i percorsi di codice utilizzati 80%/freq. Avere test che testano ogni 'throw ExceptionTypeX' o una simile guardia di programmazione difensiva che hai inserito è un 'Nice to have' non un 'must'

Quindi, fidati di te stesso o dei tuoi sviluppatori per essere completo e percorrere ogni percorso attraverso il loro codice. Sii pragmatico e non inseguire la magica copertura al 100%. Se hai il tuo codice TDD dovresti ottenere una copertura del 90% + come bonus. Usa la copertura del codice per evidenziare blocchi di codice che hai perso (non dovrebbe accadere se tu TDD però .. dato che scrivi il codice solo per fare un test pass. Nessun codice può esistere senza il suo test del partner.)

80
Gishu

La copertura del codice è ottima, ma la copertura della funzionalità è ancora migliore. Non credo di coprire ogni singola riga che scrivo. Ma credo di scrivere una copertura di prova del 100% di tutte le funzionalità che voglio fornire (anche per le funzionalità extra che sono venuto con me stesso e che non sono state discusse durante gli incontri).

Non mi interessa se avessi un codice che non è coperto dai test, ma mi piacerebbe se rifattassi il mio codice e finisse per avere un comportamento diverso. Pertanto, il 100% di copertura delle funzionalità è il mio unico obiettivo.

51
tofi9

La risposta accettata è un buon punto: non c'è un solo numero che abbia senso come standard per ogni progetto. Ci sono progetti che semplicemente non hanno bisogno di un simile standard. Dove la risposta accettata è insufficiente, a mio avviso, sta nel descrivere come si potrebbe prendere quella decisione per un determinato progetto.

Farò un tentativo di farlo. Non sono un esperto in ingegneria dei test e sarei felice di vedere una risposta più informata.

Quando impostare i requisiti di copertura del codice

Innanzitutto, perché dovresti imporre un tale standard in primo luogo? In generale, quando vuoi introdurre la fiducia empirica nel tuo processo. Cosa intendo per "empirica fiducia"? Bene, il vero obiettivo correttezza . Per la maggior parte dei software, non possiamo saperlo attraverso tutti gli input, quindi ci accontentiamo di dire che il codice è ben testato . Questo è più conoscibile, ma è ancora uno standard soggettivo: sarà sempre aperto il dibattito se lo abbiate incontrato o no. Questi dibattiti sono utili e dovrebbero verificarsi, ma mettono anche in evidenza l'incertezza.

La copertura del codice è una misurazione oggettiva: una volta visualizzato il rapporto sulla copertura, non vi è alcuna ambiguità sul fatto che gli standard siano stati soddisfatti. Dimostra la correttezza? Niente affatto, ma ha una chiara relazione con quanto ben collaudato sia il codice, che a sua volta è il nostro miglior modo per aumentare la fiducia nella sua correttezza. La copertura del codice è un'approssimazione misurabile di qualità incommensurabili a cui teniamo.

Alcuni casi specifici in cui avere uno standard empirico potrebbe aggiungere valore:

  • Per soddisfare le parti interessate. Per molti progetti, ci sono diversi attori interessati alla qualità del software che potrebbero non essere coinvolti nello sviluppo quotidiano del software (manager, lead tecnici, ecc.) Dire "stiamo andando a scrivere tutti i test di cui abbiamo veramente bisogno" non è convincente: entrambi devono fidarsi completamente, o verificare con una stretta sorveglianza continua (supponendo che abbiano persino il comprensione tecnica per farlo). Fornire standard misurabili e spiegare come si avvicinano ragionevolmente agli obiettivi reali è meglio.
  • Per normalizzare il comportamento del team. A parte gli stakeholder, se stai lavorando a un team in cui più persone stanno scrivendo codice e test, c'è spazio per l'ambiguità per ciò che qualifica come "ben collaudato". Tutti i tuoi colleghi hanno la stessa idea di quale livello di test è abbastanza buono? Probabilmente no. Come si concilia questo? Trova una metrica su cui tutti puoi essere d'accordo e accettarla come un'approssimazione ragionevole. Questo è specialmente (ma non esclusivamente) utile in team di grandi dimensioni, dove i lead potrebbero non avere una supervisione diretta sugli sviluppatori junior, per esempio. Anche le reti di fiducia contano, ma senza misurazioni oggettive, è facile che il comportamento di gruppo diventi incoerente, anche se tutti agiscono in buona fede.
  • Per essere onesto. Anche se sei l'unico sviluppatore e unico stakeholder per il tuo progetto, potresti avere alcune qualità in mente per il software. Invece di fare valutazioni soggettive in itinere su quanto sia ben collaudato il software (che funziona), è possibile utilizzare la copertura del codice come un'approssimazione ragionevole e lasciare che le macchine lo misurino per te.

Quali metriche utilizzare

La copertura del codice non è una singola metrica; ci sono diversi modi per misurare la copertura. Quello su cui potresti impostare uno standard dipende da cosa stai usando quello standard per soddisfare.

Userò due parametri comuni come esempi di quando potresti usarli per impostare gli standard:

  • Copertura informativa : quale percentuale di dichiarazioni sono state eseguite durante il test? Utile per avere un'idea della copertura fisica del tuo codice: quanto del codice che ho scritto ho effettivamente testato?
    • Questo tipo di copertura supporta un argomento di correttezza più debole, ma è anche più facile da ottenere. Se stai usando la copertura del codice per garantire che le cose vengano testate (e non come un indicatore della qualità del test oltre a quelle), la copertura delle dichiarazioni è probabilmente sufficiente.
  • Copertura del ramo : quando c'è una logica di branching (ad esempio un if), sono stati valutati entrambi i rami? Ciò fornisce un miglior senso della copertura logica del tuo codice: quanti dei possibili percorsi che il mio codice può intraprendere ho testato?
    • Questo tipo di copertura è un indicatore molto migliore che un programma è stato testato attraverso un insieme completo di input. Se stai utilizzando la copertura del codice come migliore approssimazione empirica per avere fiducia nella correttezza, dovresti stabilire degli standard basati sulla copertura delle filiali o simili.

Esistono molte altre metriche (la copertura delle linee è simile alla copertura delle dichiarazioni, ma produce risultati numerici diversi per le dichiarazioni multilinea, ad esempio, copertura condizionale e copertura dei percorsi è simile alla copertura delle filiali, ma riflette una vista più dettagliata delle possibili permutazioni di esecuzione del programma che potresti incontrare.)

Quale percentuale richiedere

Infine, tornando alla domanda originale: se si impostano gli standard di copertura del codice, quale dovrebbe essere quel numero?

Speriamo sia chiaro a questo punto che stiamo parlando di un'approssimazione per cominciare, quindi qualsiasi numero che selezioneremo sarà intrinsecamente approssimativo.

Alcuni numeri che si potrebbe scegliere:

  • 100% . Puoi scegliere questo perché vuoi essere sicuro che tutto sia testato. Questo non ti dà un'idea della qualità del test, ma ti dice che alcuni test di qualità hanno toccato ogni affermazione (o ramo, ecc.) Ancora una volta, questo torna al grado di fiducia: se la copertura è inferiore al 100% , tu conosci alcuni sottoinsiemi del tuo codice non sono stati testati.
    • Qualcuno potrebbe obiettare che questo è sciocco, e dovresti solo testare le parti del tuo codice che sono davvero importanti. Direi che dovresti anche mantenere solo le parti del tuo codice che sono davvero importanti. La copertura del codice può essere migliorata rimuovendo anche il codice non testato.
  • 99% (o 95%, altri numeri nei primi anni '90.) Appropriato nei casi in cui si desidera trasmettere un livello di confidenza simile al 100%, ma lascia un margine per non preoccuparti dell'occasionale angolo di codice difficile da testare.
  • 80% . Ho visto questo numero in uso un paio di volte e non so esattamente da dove proviene. I pensa potrebbe essere una strana appropriazione indebita della regola 80-20; generalmente, l'intento qui è mostrare che la maggior parte del tuo codice è stata testata. (Sì, il 51% sarebbe anche "il più", ma l'80% è più riflettente di ciò che la maggior parte delle persone significa di più.) Questo è appropriato per i casi di media terra in cui "bene -testato "non è una priorità elevata (non vuoi sprecare gli sforzi per i test di basso valore), ma è una priorità sufficiente a cui vorresti ancora disporre di uno standard.

Non ho visto numeri sotto l'80% nella pratica, e ho difficoltà a immaginare un caso in cui li avresti impostati. Il ruolo di questi standard è quello di aumentare la fiducia nella correttezza, e numeri inferiori all'80% non sono particolarmente ispiratori di fiducia. (Sì, questo è soggettivo, ma ancora una volta, l'idea è quella di fare la scelta soggettiva una volta quando si imposta lo standard, e quindi utilizzare una misurazione oggettiva andando avanti.)

Altre note

Quanto sopra presuppone che la correttezza sia l'obiettivo. La copertura del codice è solo informazione; potrebbe essere rilevante per altri obiettivi. Ad esempio, se sei preoccupato per la manutenibilità, probabilmente tieni conto dell'accoppiamento libero, che può essere dimostrato dalla testabilità, che a sua volta può essere misurata (in determinate mode) dalla copertura del codice. Quindi lo standard di copertura del codice fornisce una base empirica per l'approssimazione della qualità della "manutenibilità".

45
killscreen

La mia copertura di codice preferita è al 100% con un asterisco. L'asterisco viene perché preferisco usare strumenti che mi consentono di contrassegnare determinate righe come linee che "non contano". Se ho coperto il 100% delle linee che "contano", ho finito.

Il processo sottostante è:

  1. Scrivo i miei test per esercitare tutte le funzionalità e i casi Edge a cui riesco a pensare (di solito lavoro dalla documentazione).
  2. Corro gli strumenti di copertura del codice
  3. Esamino le linee oi percorsi non coperti e quelli che considero non importanti o irraggiungibili (a causa della programmazione difensiva) Contrassegno come non contando
  4. Scrivo nuovi test per coprire le linee mancanti e migliorare la documentazione se questi casi Edge non sono menzionati.

In questo modo se io e i miei collaboratori aggiungiamo un nuovo codice o cambiamo i test in futuro, c'è una linea chiara per dirci se abbiamo perso qualcosa di importante - la copertura è scesa al di sotto del 100%. Tuttavia, fornisce anche la flessibilità necessaria per affrontare le diverse priorità di test.

23
Eponymous

Avrei un altro anectode sulla copertura di test che mi piacerebbe condividere.

Abbiamo un grande progetto in cui, su Twitter, ho notato che, con 700 test unitari, abbiamo solo il 20% di copertura del codice .

Scott Hanselman ha risposto con parole di saggezza :

È GIUSTO il 20%? È il 20% che rappresenta il codice più colpito dai tuoi utenti? Potresti aggiungere altri 50 test e aggiungere solo il 2%.

Di nuovo, torna al mio Testivus sulla copertura del codice Risposta. Quanto riso dovresti mettere nel piatto? Dipende.

19
Jon Limjap

Per un sistema ben progettato, dove i test unitari hanno guidato lo sviluppo fin dall'inizio, direi che l'85% è un numero piuttosto basso. Le classi piccole progettate per essere testabili non dovrebbero essere difficili da coprire meglio di così.

È facile ignorare questa domanda con qualcosa di simile:

  • Le linee coperte non sono uguali alla logica testata e non si dovrebbe leggere troppo nella percentuale.

È vero, ma ci sono alcuni punti importanti da fare sulla copertura del codice. Nella mia esperienza questa metrica è in realtà abbastanza utile, se usata correttamente. Detto questo, non ho visto tutti i sistemi e sono sicuro che ce ne sono molti in cui è difficile vedere l'analisi della copertura del codice aggiungendo un valore reale. Il codice può apparire così diverso e lo scopo del framework di test disponibile può variare.

Inoltre, il mio ragionamento riguarda principalmente loop di feedback test piuttosto brevi. Per il prodotto che sto sviluppando il ciclo di feedback più breve è abbastanza flessibile, che copre tutto, dai test di classe alla segnalazione inter-processo. La verifica di un sottoprodotto consegnabile richiede in genere 5 minuti e per un ciclo di feedback così breve è infatti possibile utilizzare i risultati del test (e in particolare la metrica di copertura del codice che stiamo osservando qui) per rifiutare o accettare i commit nel repository.

Quando si utilizza la metrica di copertura del codice non si dovrebbe avere solo una percentuale fissa (arbitraria) che deve essere soddisfatta. Fare questo non offre i veri benefici dell'analisi della copertura del codice secondo me . Invece, definire le seguenti metriche:

  • Low Water Mark (LWM), il numero più basso di linee scoperte mai visto nel sistema in prova
  • High Water Mark (HWM), la più alta percentuale di copertura del codice mai vista per il sistema in prova

Il nuovo codice può essere aggiunto solo se non superiamo il LWM e non scendiamo sotto l'HWM. In altre parole, la copertura del codice è non consentita per diminuire , e il nuovo codice dovrebbe essere coperto. Nota come dico dovrebbe e non deve (spiegato sotto).

Ma questo non significa che sarà impossibile ripulire la vecchia spazzatura ben collaudata che non serve più? Sì, ed è per questo che devi essere pragmatico riguardo a queste cose. Ci sono situazioni in cui le regole devono essere violate, ma per la tua integrazione giornaliera tipica la mia esperienza è che queste metriche sono abbastanza utili. Danno le seguenti due implicazioni.

  • Il codice verificabile è promosso. Quando aggiungi un nuovo codice devi davvero fare uno sforzo per rendere il codice testabile, perché dovrai provare a coprire tutto con i tuoi casi di test. Il codice verificabile di solito è una buona cosa.

  • La copertura del test per il codice legacy sta aumentando nel tempo. Quando si aggiunge un nuovo codice e non si è in grado di coprirlo con un caso di test, si può provare a coprire qualche codice legacy invece di aggirare la regola LWM. Questo inganno, a volte necessario, dà almeno l'effetto collaterale positivo che la copertura del codice legacy aumenterà nel tempo, rendendo l'applicazione apparentemente rigorosa di queste regole piuttosto pragmatica nella pratica.

E ancora, se il ciclo di feedback è troppo lungo, potrebbe non essere pratico impostare qualcosa di simile nel processo di integrazione.

Vorrei anche menzionare due ulteriori vantaggi generali della metrica di copertura del codice.

  • L'analisi della copertura del codice fa parte dell'analisi del codice dinamico (al contrario di quella statica, cioè Lint). Problemi rilevati durante l'analisi dinamica del codice (da strumenti come la famiglia purify, http://www-03.ibm.com/software/products/en/rational-purify-family ) sono cose come la lettura di memorie non inizializzate (UMR), perdite di memoria, ecc. Questi problemi possono essere trovati solo se il codice è coperto da un caso di test eseguito . Il codice che è il più difficile da coprire in un caso di test è in genere i casi anomali nel sistema, ma se si desidera che il sistema abbia esito negativo con garbo (ad es. Traccia di errore anziché arresto anomalo) si potrebbe voler fare un certo sforzo per coprire i casi anomali anche nell'analisi dinamica del codice. Con un po 'di sfortuna, un UMR può portare a un segfault o peggio.

  • Le persone sono orgogliose di mantenere il 100% per il nuovo codice e le persone discutono problemi di test con una passione simile a quella di altri problemi di implementazione. In che modo questa funzione può essere scritta in modo più verificabile? Come andresti nel cercare di coprire questo caso anormale, ecc.

E un negativo, per completezza.

  • In un grande progetto con molti sviluppatori coinvolti, nessuno sarà certo un genio del test. Alcune persone tendono a utilizzare la metrica di copertura del codice come prova che il codice è stato testato e questo è molto lontano dalla verità , come menzionato in molte delle altre risposte a questa domanda. È una metrica che può darti dei benefici se usata correttamente, ma se usata in modo scorretto può portare a test errati. A parte gli effetti collaterali di grande valore menzionati sopra, una linea coperta mostra solo che il sistema in prova può raggiungere quella linea per alcuni dati di input e che può essere eseguito senza bloccarsi o bloccarsi.
7
Martin G

Se questo fosse un mondo perfetto, il 100% del codice sarebbe coperto dai test unitari. Tuttavia, poiché questo NON è un mondo perfetto, è una questione di ciò per cui hai tempo. Di conseguenza, consiglio di concentrarsi meno su una percentuale specifica e concentrarsi maggiormente sulle aree critiche. Se il tuo codice è ben scritto (o almeno un suo facsimile ragionevole) ci dovrebbero essere diversi punti chiave in cui le API sono esposte ad altri codici.

Concentrare i tuoi sforzi di test su queste API. Assicurarsi che le API siano 1) ben documentate e 2) che i casi di test scritti corrispondano alla documentazione. Se i risultati attesi non coincidono con i documenti, allora c'è un bug nel codice, nella documentazione o nei casi di test. Tutto ciò è buono per controllare.

In bocca al lupo!

7
64BitBob

L'85% sarebbe un buon punto di partenza per i criteri di check-in.

Probabilmente avrei scelto una varietà di barre più alte per i criteri di spedizione, a seconda della criticità dei sottosistemi/componenti testati.

5
stephbu

Molti negozi non valutano i test, quindi se siete sopra lo zero almeno c'è un certo apprezzamento del valore - così probabilmente il non-zero non è male dato che molti sono ancora zero.

Nel mondo .Net le persone citano spesso l'80% come ragionevole. Ma lo dicono a livello di soluzione. Preferisco misurare a livello di progetto: il 30% potrebbe andare bene per il progetto dell'interfaccia utente se hai selenio, ecc. O test manuali, il 20% per il progetto livello dati potrebbe andare bene, ma il 95% + potrebbe essere abbastanza realizzabile per il business livello delle regole, se non del tutto necessario. Quindi la copertura complessiva può essere, ad esempio, del 60%, ma la logica aziendale critica potrebbe essere molto più elevata.

Ho anche sentito questo: aspira al 100% e avrai raggiunto l'80%; ma aspira all'80% e colpisci il 40%.

In conclusione: applica la regola 80:20 e lascia che il conteggio dei bug della tua app ti guidi.

5
Greg Trevellick

Io uso la cobertura e, qualunque sia la percentuale, ti consiglio di mantenere aggiornati i valori nel task di verifica della cobertura. Come minimo, continua ad aumentare totallinerate e totalbranchrate appena sotto la copertura corrente, ma mai abbassa questi valori. Legare anche la proprietà di errore di build Ant a questa attività. Se la build fallisce a causa della mancanza di copertura, conosci il codice aggiunto di qualcuno ma non lo hai testato. Esempio:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />
4
Gary Kephart

Quando penso che il mio codice non sia sufficientemente testato, e non sono sicuro di cosa testare, uso la copertura per aiutarmi a decidere cosa testare dopo.

Se aumento la copertura in un test unitario, so che questo test unitario vale qualcosa.

Questo vale per il codice non coperto, coperto al 50% o coperto al 97%.

4
brickner

La copertura del codice è solo un'altra metrica. Di per sé, può essere molto fuorviante (vedere www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ) . Il tuo obiettivo non dovrebbe quindi essere quello di ottenere una copertura del 100% del codice, ma piuttosto di assicurarti di testare tutti gli scenari rilevanti della tua applicazione.

4
klementtt

In generale, dai numerosi documenti sulle best practice di eccellenza ingegneristica che ho letto, l'80% per il nuovo codice nei test unitari è il punto che offre il miglior rendimento. Andando al di sopra di questo CC% si ottiene una minore quantità di difetti per la quantità di sforzo esercitata. Questa è una best practice utilizzata da molte grandi aziende.

Sfortunatamente, la maggior parte di questi risultati sono interni alle aziende, quindi non ci sono letterature pubbliche a cui posso indirizzarti.

3
user17222

La copertura del codice è ottima, ma solo finché i benefici che ne derivano superano i costi/gli sforzi per raggiungerla.

Abbiamo lavorato ad uno standard dell'80% per un po 'di tempo, tuttavia abbiamo appena deciso di abbandonarlo e invece concentrarci maggiormente sui nostri test. Concentrandosi sulla complessa logica aziendale, ecc.

Questa decisione è stata presa a causa del crescente periodo di tempo trascorso a inseguire la copertura del codice e il mantenimento dei test unitari esistenti. Sentivamo di essere arrivati ​​al punto in cui il vantaggio che ricevevamo dalla nostra copertura del codice era considerato inferiore allo sforzo che dovevamo compiere per raggiungerlo.

3
Simon Keep

Se hai fatto test unitari per un periodo di tempo decente, non vedo alcun motivo per non avvicinarsi al 95% +. Tuttavia, come minimo, ho sempre lavorato con l'80%, anche se nuovo per i test.

Questo numero dovrebbe includere solo il codice scritto nel progetto (esclude framework, plugin, ecc.) E forse anche escludere determinate classi composte interamente da codice scritto di chiamate a codice esterno. Questo tipo di chiamata dovrebbe essere deriso/stoppato.

3
Tony Pitale

Preferisco fare BDD, che utilizza una combinazione di test di accettazione automatici, possibilmente altri test di integrazione e test di unità. La domanda per me è quale dovrebbe essere la copertura target della suite di test automatizzata nel suo insieme.

A parte questo, la risposta dipende dalla metodologia, dalla lingua e dai test e dagli strumenti di copertura. Quando si esegue TDD in Ruby o Python non è difficile mantenere una copertura del 100%, e vale la pena farlo. È molto più facile gestire una copertura del 100% rispetto alla copertura del 90%. Cioè, è molto più facile colmare le lacune di copertura man mano che appaiono (e quando si fa Gli intervalli di copertura del pozzo TDD sono rari e di solito valgono il tuo tempo) piuttosto che gestire un elenco di lacune di copertura che non hai ottenuto e perdere le regressioni di copertura a causa del tuo costante background di codice scoperto.

La risposta dipende anche dalla storia del tuo progetto. Ho solo trovato che quanto sopra è pratico nei progetti gestiti in questo modo fin dall'inizio. Ho notevolmente migliorato la copertura di progetti legacy di grandi dimensioni, e ne è valsa la pena, ma non ho mai trovato pratico tornare indietro e colmare ogni lacuna di copertura, perché il vecchio codice non testato non è stato ben compreso per farlo correttamente e velocemente.

3
Dave Schweisguth

La mia risposta a questo enigma è di avere una copertura del 100% del codice che puoi testare e una copertura del 0% del codice che non puoi testare.

La mia pratica corrente in Python è quella di dividere i miei moduli .py in due cartelle: app1/e app2/e quando si eseguono test di unità calcolare la copertura di queste due cartelle e verificare visivamente (I deve automatizza questo giorno) che app1 ha una copertura del 100% e app2 ha una copertura dello 0%.

Quando/se trovo che questi numeri differiscono dallo standard I investigare e alterare il design del codice in modo tale che la copertura sia conforme allo standard.

Ciò significa che posso consigliare il raggiungimento del 100% di copertura della linea del codice della biblioteca.

Di tanto in tanto riesamina app2/per vedere se posso testare qualsiasi codice lì, e se posso posso spostarlo in app1 /

Ora non sono troppo preoccupato per la copertura aggregata perché può variare in modo selvaggio a seconda delle dimensioni del progetto, ma in genere ho visto il 70% oltre il 90%.

Con python, dovrei essere in grado di ideare un smoke test che possa far funzionare automaticamente la mia app durante la misurazione della copertura e, si spera, ottenere un aggreagate del 100% quando si combina il test del fumo con figure inedite.

2
quamrana

Controlla Crap4j . È un approccio un po 'più sofisticato rispetto alla copertura del codice diretto. Combina le misurazioni della copertura del codice con le misurazioni della complessità e quindi mostra quale codice complesso non è attualmente testato.

2
Don Kirkby

Secondo me, la risposta è "Dipende da quanto tempo hai". Cerco di raggiungere il 100% ma non faccio storie se non lo ottengo con il tempo che ho.

Quando scrivo test unitari, indosso un cappello diverso rispetto al cappello che indosso quando sviluppo il codice di produzione. Penso a ciò che il codice testato pretende di fare e quali sono le situazioni che possono interromperlo.

Di solito seguo i seguenti criteri o regole:

  1. Che il Test unitario dovrebbe essere una forma di documentazione su quale sia il comportamento previsto dei miei codici, es. l'output atteso dato un certo input e le eccezioni che può generare che i client potrebbero voler intercettare (cosa dovrebbero sapere gli utenti del mio codice?)

  2. Che il test unitario dovrebbe aiutarmi a scoprire quali sono le condizioni che potrei non aver ancora pensato. (Come rendere il mio codice stabile e robusto?)

Se queste due regole non producono una copertura del 100%, allora così sia. Ma una volta, ho il tempo, analizzo i blocchi e le linee scoperti e stabilisco se ci sono ancora casi di test senza test unitari o se il codice deve essere refactored per eliminare i codici non necessari.

2
Mark Menchavez

Dipende molto dalla tua applicazione. Ad esempio, alcune applicazioni consistono principalmente in codice GUI che non può essere testato unitamente.

1
Thomas

Non penso che ci possa essere una tale regola del B/N.
Il codice dovrebbe essere rivisto, con particolare attenzione ai dettagli critici.
Tuttavia, se non è stato testato, ha un bug!

1
Nescio

Risposta breve: 60-80%

Risposta lunga: penso che dipenda totalmente dalla natura del tuo progetto. Generalmente avvio un progetto per unità testando ogni pezzo pratico. Con la prima "release" del progetto dovresti avere una percentuale di base piuttosto buona basata sul tipo di programmazione che stai facendo. A quel punto puoi iniziare a "forzare" una copertura minima del codice.

1
user11087

A seconda della criticità del codice, ovunque dal 75% all'85% è una buona regola empirica. Il codice di spedizione dovrebbe essere sicuramente testato in modo più approfondito rispetto alle utility domestiche, ecc.

1
William Keller

Ciò deve dipendere dalla fase del ciclo di vita dello sviluppo dell'applicazione in cui ti trovi.

Se sei stato in sviluppo per un po 'e hai già un sacco di codice implementato e stai solo ora comprendendo che hai bisogno di pensare alla copertura del codice, allora devi controllare la copertura corrente (se esiste) e poi usare quella linea di base per impostare le pietre miliari di ogni sprint (o un aumento medio in un periodo di sprint), il che significa assumere il debito del codice pur continuando a fornire valore all'utente finale (almeno nella mia esperienza l'utente finale non si cura un po 'se hai aumentato il test copertura se non vedono nuove funzionalità).

A seconda del tuo dominio, non è irragionevole riprendere per il 95%, ma dovrei dire che in media guarderai un caso medio dall'85% al ​​90%.

1
codeLes

Penso che il miglior sintomo della corretta copertura del codice sia la quantità di problemi concreti che i test unitari aiutano a risolvere è ragionevolmente corrispondente alla dimensione del codice di test unitario che hai creato.

1
dimarzionist

Penso che ciò che può importare di più sia sapere quale sia il trend di copertura nel tempo e capire i motivi dei cambiamenti nella tendenza. Se si osservano i cambiamenti nella tendenza come positivi o negativi dipenderà dall'analisi del motivo.

1
Rob Scott

Dal post sul Testivus penso che il contesto della risposta dovrebbe essere il secondo programmatore. Detto questo da un punto di vista pratico, abbiamo bisogno di parametri/obiettivi per cui lottare. Considero che questo può essere "testato" in un processo Agile analizzando il codice che abbiamo l'architettura, la funzionalità (storie degli utenti) e poi ne viene fuori un numero. Sulla base della mia esperienza nell'area Telecom, direi che il 60% è un buon valore da controllare.

0
D Lovece

Abbiamo scelto come target> 80% fino a qualche giorno fa, ma dopo aver utilizzato un sacco di codice generato, non ci interessa% age, ma piuttosto che il revisore faccia una chiamata sulla copertura richiesta.

0
reva