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

StackOverflow https://stackoverflow.com/questions/90002

Domanda

Se dovessi imporre una percentuale minima di copertura del codice per i test unitari, magari anche come requisito per impegnarti in un repository, quale sarebbe?

Per favore spiega come sei arrivato alla tua risposta (poiché se tutto quello che avessi fatto fosse stato scegliere un numero, avrei potuto farlo da solo ;)

È stato utile?

Soluzione

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

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

Testivus sulla copertura del test

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

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

Il grande maestro rispose:

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

Il programmatore sorrise, si inchinò e a sinistra.

...

Più tardi quel giorno, un secondo programmatore ha posto 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, che sembra perplesso, ha risposto:

“Come posso dirtelo?Dipende da quante persone hai bisogno di nutrirti, di quanto sono affamati, di quale altro cibo stai servendo, quanto riso hai disponibile e così via. "

“Esattamente”, disse il grande maestro.

Il secondo programmatore sorrise, si inchinò e a sinistra.

...

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

"Ottanta per cento e non meno!" Rispose il maestro con una voce severa, battendo il pugno sul tavolo.

Il terzo programmatore sorrise, si inchinò e a sinistra.

...

Dopo quest'ultima risposta, un giovane apprendista si è avvicinato al grande maestro:

“Grande maestro, oggi ho sentito che rispondi alla stessa domanda sulla copertura del codice con tre diverse risposte.Perché?"

Il grande maestro si alzò dalla sedia:

"Vieni a prendere un po' di tè fresco con me e ne parliamo."

Dopo aver riempito le loro tazze con un tè verde caldo fumante, il grande maestro ha iniziato a rispondere:

“Il primo programmatore è nuovo e ha appena iniziato con i test.In questo momento ha molto codice e nessun test.Ha molta strada da fare;Concentrarsi sulla copertura del codice in questo momento sarebbe deprimente e abbastanza inutile.È meglio che si abitua a scrivere e eseguire alcuni test.Può preoccuparsi della copertura in seguito. "

“Il secondo programmatore, d'altra parte, è abbastanza esperienza sia nella programmazione che nel 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 quei fattori meglio di me - è il suo codice dopo tutto .Non esiste una risposta singola, semplice, ed è abbastanza intelligente da gestire la verità e lavorare con quello. "

"Capisco", ha detto il giovane apprendista, "ma se non esiste una singola risposta semplice, allora perché hai risposto al terzo programmatore" ottanta percento e non di meno "?"

Il grande maestro rise così forte e forte che la sua pancia, prove che beveva più che un semplice tè verde, si alzò su e giù.

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

Il giovane apprendista e il Great Master brizzera hanno finito di bere il loro tè in silenzio contemplativo.

Altri suggerimenti

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

  • Potresti ottenere il 100% colpendo tutte le linee una volta.Tuttavia potresti comunque perdere il test di una sequenza particolare (percorso logico) in cui vengono colpite quelle linee.
  • Non è stato possibile ottenere un 100% ma hai comunque testato tutti i percorsi di codice utilizzati all'80%/frequenza.Avere test che mettono alla prova ogni 'lancio ExceptionTypeX' o protezione di programmazione difensiva simile che hai inserito è un 'bello da avere', non un 'must have'

Quindi fidati di te stesso o dei tuoi sviluppatori per essere scrupolosi e coprire ogni percorso attraverso il loro codice.Sii pragmatico e non rincorrere la magica copertura del 100%.Se aggiungi il tuo codice TDD dovresti ottenere una copertura superiore al 90% come bonus.Usa la copertura del codice per evidenziare pezzi di codice che ti sei perso (non dovrebbe accadere se usi TDD...poiché scrivi il codice solo per effettuare un test.Nessun codice può esistere senza il suo test partner.)

La copertura del codice è ottima, ma la copertura delle funzionalità è ancora migliore.Non credo nel coprire ogni singola riga che scrivo.Ma credo nello scrivere una copertura di prova al 100% di tutte le funzionalità che voglio fornire (anche per le funzionalità extra interessanti che ho portato con me e che non sono state discusse durante le riunioni).

Non mi interessa se avrei del codice che non è coperto dai test, ma mi importerebbe se rifattorizzassi il mio codice e finissi per avere un comportamento diverso.Pertanto, il mio unico obiettivo è la copertura delle funzionalità al 100%.

La risposta accettata è giusta: non esiste un singolo numero che abbia senso come standard per ogni progetto.Ci sono progetti che semplicemente non necessitano di tale standard.Il punto in cui la risposta accettata non è sufficiente, secondo me, è nel descrivere come si potrebbe prendere quella decisione per un dato progetto.

Proverò a 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é vorresti imporre uno standard del genere?In generale, quando vuoi introdurre la fiducia empirica nel tuo processo.Cosa intendo per “confidenza empirica”?Ebbene, il vero obiettivo correttezza.Per la maggior parte dei software, non è possibile saperlo per tutti gli input, quindi ci accontentiamo di dire che il codice lo è ben testato.Questo è più conoscibile, ma è ancora uno standard soggettivo:Sarà sempre aperto il dibattito se l’hai incontrato o meno.Questi dibattiti sono utili e dovrebbero aver luogo, ma espongono anche incertezza.

Copertura del codice è una misurazione oggettiva:Una volta visualizzato il rapporto di copertura, non vi è alcuna ambiguità sull'utilità o meno degli standard rispettati.Dimostra la correttezza?Niente affatto, ma ha una chiara relazione con quanto è ben testato il codice, che a sua volta è il nostro modo migliore per aumentare la fiducia nella sua correttezza.La copertura del codice è un'approssimazione misurabile delle qualità incommensurabili a cui teniamo.

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

  • Per soddisfare gli stakeholder. Per molti progetti, ci sono vari attori interessati alla qualità del software che potrebbero non essere coinvolti nello sviluppo quotidiano del software (manager, responsabili tecnici, ecc.) dicendo "scriveremo tutto il test di cui abbiamo veramente bisogno" non è convincente:Devono fidarsi completamente o verificare con una supervisione attenta e continua (supponendo che abbiano anche la conoscenza tecnica per farlo). Fornire standard misurabili e spiegare come si avvicinano ragionevolmente agli obiettivi effettivi è meglio.
  • Normalizzare il comportamento della squadra. A parte le parti interessate, se stai lavorando a un team in cui più persone scrivono codice e test, c'è spazio per l'ambiguità per ciò che si qualifica come "ben testato". Tutti i tuoi colleghi hanno la stessa idea di quale livello di test è abbastanza buono?Probabilmente no.Come conciliare questo?Trova una metrica su cui tutti siano d'accordo e accettala come un'approssimazione ragionevole.Ciò è particolarmente (ma non esclusivamente) utile nei team di grandi dimensioni, dove i leader potrebbero non avere una supervisione diretta sugli sviluppatori junior, ad esempio.Anche le reti di fiducia sono importanti, ma senza misurazioni oggettive è facile che il comportamento del gruppo diventi incoerente, anche se tutti agiscono in buona fede.
  • Per mantenerti onesto. Anche se sei l'unico sviluppatore e l'unico stakeholder del tuo progetto, potresti avere in mente determinate qualità per il software.Invece di effettuare valutazioni soggettive continue su quanto sia ben testato il software (il che richiede lavoro), puoi utilizzare la copertura del codice come approssimazione ragionevole e lasciare che le macchine la misurino per te.

Quali metriche utilizzare

La copertura del codice non è un singolo parametro;esistono diversi modi per misurare la copertura.Quello su cui potresti stabilire uno standard dipende da cosa stai utilizzando quello standard per soddisfare.

Utilizzerò due parametri comuni come esempi di quando potresti utilizzarli per stabilire degli standard:

  • Copertura della dichiarazione:Quale percentuale di istruzioni sono state eseguite durante il test?Utile per farsi un'idea 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 solo utilizzando la copertura del codice per assicurarti Quello le cose vengono testate (e non come indicatore della qualità del test oltre a ciò), quindi la copertura delle dichiarazioni è probabilmente sufficiente.
  • Copertura delle filiali:Quando è presente una logica di ramificazione (ad es.UN if), sono stati valutati entrambi i rami?Questo dà un senso migliore del copertura logica del tuo codice:Quanti dei possibili percorsi che il mio codice potrebbe intraprendere ho testato?
    • Questo tipo di copertura è un indicatore molto migliore del fatto che un programma è stato testato su una serie completa di input.Se utilizzi la copertura del codice come migliore approssimazione empirica per garantire la correttezza, dovresti stabilire standard basati sulla copertura delle filiali o simili.

Esistono molti altri parametri (la copertura della riga è simile alla copertura dell'istruzione, ma produce risultati numerici diversi per istruzioni su più righe, ad esempio;la copertura condizionale e la copertura del percorso sono simili alla copertura delle filiali, ma riflettono una visione più dettagliata delle possibili permutazioni dell'esecuzione del programma che potresti incontrare.)

Quale percentuale richiedere

Infine, torniamo alla domanda iniziale:Se imposti gli standard di copertura del codice, quale dovrebbe essere quel numero?

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

Alcuni numeri che si potrebbero scegliere:

  • 100%.Potresti scegliere questo perché vuoi essere sicuro che tutto sia testato.Questo non ti dà alcuna informazione sulla qualità del test, ma ti dice che qualche test di una certa qualità ha toccato ogni affermazione (o ramo, ecc.). Ancora una volta, questo torna al grado di confidenza:Se la tua copertura è inferiore al 100%, tu Sapere alcuni sottoinsiemi del codice non sono stati testati.
    • Alcuni potrebbero obiettare che questo è sciocco e che dovresti testare solo le parti del tuo codice che sono veramente importanti.Direi che dovresti anche mantenere solo le parti del tuo codice che sono veramente importanti.La copertura del codice può essere migliorata rimuovendo anche il codice non testato.
  • 99% (o 95%, altri numeri negli anni Novanta.) Appropriato nei casi in cui si desidera trasmettere un livello di sicurezza simile al 100%, ma lascia un po' di margine per non preoccuparti di qualche angolo di codice difficile da testare.
  • 80%.Ho visto questo numero in uso alcune volte e non so del tutto da dove provenga.IO pensare potrebbe trattarsi di una strana appropriazione indebita della regola 80-20;generalmente, l'intento qui è dimostrarlo maggior parte del tuo codice è testato.(Sì, anche il 51% sarebbe "la maggior parte", ma l'80% riflette maggiormente ciò che la maggior parte delle persone Significare dalla maggior parte.) Questo è appropriato per i casi di medio livello in cui "ben testato" non è una priorità alta (non vuoi sprecare energie in test di basso valore), ma è una priorità sufficiente per cui dovresti comunque mi piacerebbe avere qualche standard in atto.

In pratica non ho visto numeri inferiori all'80% e ho difficoltà a immaginare un caso in cui si potrebbero impostarli.Il ruolo di questi standard è quello di aumentare la fiducia nella correttezza, e i numeri inferiori all’80% non ispirano particolarmente fiducia.(Sì, questo è soggettivo, ma ancora una volta, l'idea è di fare la scelta soggettiva una volta stabilita lo standard e poi utilizzare una misurazione oggettiva in futuro.)

Altre note

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

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

Il processo sottostante è:

  1. Scrivo i miei test per esercitare tutte le funzionalità e i casi limite a cui riesco a pensare (di solito lavorando dalla documentazione).
  2. Eseguo gli strumenti di copertura del codice
  3. Esamino eventuali linee o percorsi non coperti e quelli che ritengo non importanti o irraggiungibili (a causa della programmazione difensiva) contrassegno come non conteggiati
  4. Scrivo nuovi test per coprire le righe mancanti e migliorare la documentazione se questi casi limite non vengono menzionati.

In questo modo se io e i miei collaboratori aggiungiamo nuovo codice o modifichiamo i test in futuro, c'è una linea luminosa che ci dice se abbiamo perso qualcosa di importante: la copertura è scesa sotto il 100%.Tuttavia, offre anche la flessibilità necessaria per gestire diverse priorità di test.

Avrei un altro aneddoto sulla copertura del test che vorrei condividere.

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

Scott Hanselmann ha risposto con perle di saggezza:

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

Ancora una volta, tutto torna al mio Testimonianza sulla copertura del codice Risposta.Quanto riso mettere nella pentola?Dipende.

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

Concentra i tuoi sforzi di test su queste API.Assicurati che le API siano 1) ben documentate e 2) dispongano di casi di test scritti che corrispondano alla documentazione.Se i risultati attesi non corrispondono ai documenti, significa che è presente un bug nel codice, nella documentazione o nei casi di test.Tutti elementi che è bene esaminare.

Buona fortuna!

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

È facile liquidare questa domanda con qualcosa del tipo:

  • Le linee coperte non equivalgono a una logica testata e non si dovrebbe leggere troppo nella percentuale.

È vero, ma ci sono alcuni punti importanti da sottolineare riguardo alla copertura del codice.Nella mia esperienza questa metrica è in realtà abbastanza utile, se utilizzata correttamente.Detto questo, non ho visto tutti i sistemi e sono sicuro che ce ne sono tantissimi in cui è difficile vedere l'analisi della copertura del codice aggiungere un valore reale.Il codice può apparire molto diverso e l'ambito del framework di test disponibile può variare.

Inoltre, il mio ragionamento riguarda principalmente cicli di feedback di test piuttosto brevi.Per il prodotto che sto sviluppando, il ciclo di feedback più breve è abbastanza flessibile e copre tutto, dai test in classe alla segnalazione tra processi.Testare 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 esaminando 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) da soddisfare. A mio avviso, ciò non offre i reali vantaggi dell'analisi della copertura del codice.Definire invece 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 percentuale di copertura del codice più alta mai vista per il sistema in prova

Il nuovo codice può essere aggiunto solo se non andiamo al di sopra dell'LWM e non scendiamo al di sotto dell'HWM.In altre parole, la copertura del codice è non è consentito diminuire, e il nuovo codice dovrebbe essere coperto.Nota come dico "dovrebbe" e "non deve" (spiegato di seguito).

Ma questo non significa forse che sarà impossibile ripulire i rifiuti vecchi e collaudati che non servono più?Sì, ed è per questo che devi essere pragmatico su queste cose.Ci sono situazioni in cui le regole devono essere infrante, ma per la tua tipica integrazione quotidiana, ho sperimentato che questi parametri sono piuttosto utili.Danno le seguenti due implicazioni.

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

  • La copertura dei test per il codice legacy aumenta nel tempo.Quando si aggiunge nuovo codice e non si è in grado di coprirlo con un caso di test, si può provare a coprire del codice legacy invece di aggirare la regola LWM.Questo imbroglio talvolta 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 essere del tutto poco pratico impostare qualcosa di simile nel processo di integrazione.

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

  • L'analisi della copertura del codice fa parte dell'analisi dinamica del codice (al contrario di quella statica, ad es.Lanugine).Problemi riscontrati 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 letture di memoria non inizializzata (UMR), perdite di memoria, ecc. Questi problemi possono essere rilevati solo se il codice è coperto da un caso di test eseguito.Il codice più difficile da coprire in un caso di test è solitamente quello dei casi anomali nel sistema, ma se si desidera che il sistema fallisca correttamente (ad es.traccia degli errori invece del crash) potresti voler fare qualche 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 discutono dei problemi di test con una passione simile a quella degli altri problemi di implementazione.Come è possibile scrivere questa funzione in modo più testabile?Come faresti per cercare di coprire questo caso anomalo, ecc.

E un negativo, per completezza.

  • In un grande progetto con molti sviluppatori coinvolti, non tutti saranno sicuramente dei geni dei 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 altre risposte a questa domanda.È UNA metrica che può darti alcuni vantaggi se utilizzata correttamente, ma se viene utilizzata in modo improprio può infatti portare a test errati.A parte gli effetti collaterali molto preziosi menzionati sopra, una linea coperta mostra solo che il sistema sotto test può raggiungere quella linea per alcuni dati di input e che può essere eseguito senza bloccarsi o bloccarsi.

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

Probabilmente sceglierei una serie di criteri più alti per i criteri di spedizione, a seconda della criticità dei sottosistemi/componenti da testare.

Molti negozi non danno valore ai test, quindi se sei sopra lo zero almeno c'è un certo apprezzamento del valore, quindi probabilmente un valore diverso da zero non è negativo poiché molti sono ancora zero.

Nel mondo .Net le persone spesso citano l'80% come ragionevole.Ma questo 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 Selenium, ecc. o test manuali, il 20% per il progetto del livello dati potrebbe andare bene, ma il 95%+ potrebbe essere abbastanza realizzabile per il livello delle regole aziendali, se non del tutto necessario.Pertanto la copertura complessiva potrebbe essere, diciamo, del 60%, ma la logica aziendale critica potrebbe essere molto più elevata.

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

Linea di fondo:Applica la regola 80:20 e lascia che il conteggio dei bug della tua app ti guidi.

Utilizzo cobertura e, qualunque sia la percentuale, consiglierei di mantenere aggiornati i valori nell'attività di controllo cobertura.Come minimo, continua ad aumentare totallinerate e totalbranchrate appena al di sotto della tua copertura attuale, ma Mai abbassare quei valori.Collega anche la proprietà di errore di compilazione Ant a questa attività.Se la compilazione 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" />

Quando penso che il mio codice non sia stato testato abbastanza e non sono sicuro di cosa testare dopo, utilizzo 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%.

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

Se hai eseguito test unitari per un discreto periodo di tempo, non vedo motivo per cui non dovrebbe avvicinarsi al 95%+.Tuttavia, come minimo, ho sempre lavorato con l'80%, anche quando ero nuovo ai test.

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

In generale, dai numerosi documenti sulle migliori pratiche di eccellenza ingegneristica che ho letto, l'80% per il nuovo codice nei test unitari è il punto che produce il miglior rendimento.Andare oltre il CC% produce una quantità inferiore di difetti per la quantità di sforzo esercitato.Questa è una best practice utilizzata da molte grandi aziende.

Sfortunatamente, la maggior parte di questi risultati sono interni alle aziende, quindi non esiste letteratura pubblica a cui posso indicarti.

La copertura del codice è ottima, ma solo finché i vantaggi che se ne ottengono superano il costo/sforzo per realizzarla.

Lavoriamo da tempo a uno standard dell'80%, tuttavia abbiamo appena deciso di abbandonarlo e di concentrarci invece maggiormente sui nostri test.Concentrarsi sulla complessa logica aziendale, ecc.

Questa decisione è stata presa a causa della crescente quantità di tempo che abbiamo dedicato alla ricerca della copertura del codice e al mantenimento degli unit test esistenti.Sentivamo di essere arrivati ​​al punto in cui il vantaggio che stavamo ottenendo dalla nostra copertura del codice era considerato inferiore allo sforzo che dovevamo compiere per raggiungerlo.

Preferisco eseguire BDD, che utilizza una combinazione di test di accettazione automatizzati, possibilmente altri test di integrazione e test unitari.La domanda per me è quale dovrebbe essere la copertura target della suite di test automatizzati nel suo insieme.

A parte questo, la risposta dipende dalla metodologia, dalla lingua e dagli strumenti di test e copertura.Quando si esegue TDD in Ruby o Python non è difficile mantenere una copertura del 100% e vale la pena farlo. È molto più semplice gestire una copertura del 100% rispetto a una copertura del 90% circa. Cioè, è molto più semplice colmare le lacune di copertura non appena si presentano (e quando si esegue bene il TDD le lacune di copertura sono rare e di solito valgono il tuo tempo) piuttosto che gestire un elenco di lacune di copertura che non sei riuscito a raggiungere e perdere la copertura regressioni dovute al tuo costante background di codice scoperto.

La risposta dipende anche dalla storia del tuo progetto.Ho trovato quanto sopra pratico solo nei progetti gestiti in questo modo fin dall'inizio.Ho notevolmente migliorato la copertura di grandi progetti legacy, 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 è sufficientemente compreso per farlo correttamente e velocemente.

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

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

La mia pratica attuale in Python è dividere i miei moduli .py in due cartelle:app1/ e app2/ e durante l'esecuzione dei test unitari calcola la copertura di queste due cartelle e controlla visivamente (I dovere automatizzarlo un giorno) che l'app1 abbia una copertura del 100% e l'app2 abbia una copertura dello 0%.

Quando/se scopro che questi numeri differiscono dallo standard, indago e modifico la struttura del codice in modo che la copertura sia conforme allo standard.

Ciò significa che posso consigliare di ottenere una copertura della riga del 100% del codice della libreria.

Occasionalmente rivedo anche app2/ per vedere se posso testare qualche codice lì e, se posso, lo sposto in app1/

Ora non sono troppo preoccupato per la copertura complessiva perché può variare notevolmente a seconda delle dimensioni del progetto, ma generalmente ho visto dal 70% a oltre il 90%.

Con Python, dovrei essere in grado di ideare un test del fumo che possa eseguire automaticamente la mia app mentre misura la copertura e, si spera, ottenere un aggregato del 100% combinando il test del fumo con i dati unittest.

Visualizzazione della copertura da un'altra prospettiva:Il codice ben scritto con un chiaro flusso di controllo è il codice più facile da coprire, il più facile da leggere e solitamente il codice con meno bug.Scrivendo il codice pensando alla chiarezza e alla copribilità e scrivendo gli unit test in parallelo al codice, ottieni i migliori risultati IMHO.

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

Quando scrivo unit test, indosso un cappello diverso rispetto a quello che indosso quando sviluppo il codice di produzione.Penso a cosa pretende di fare il codice testato e quali sono le situazioni che possono romperlo.

Di solito seguo i seguenti criteri o regole:

  1. Che lo Unit Test dovrebbe essere una forma di documentazione su quale è il comportamento previsto dei miei codici, ad es.l'output previsto dato un determinato input e le eccezioni che potrebbe generare che i client potrebbero voler catturare (cosa dovrebbero sapere gli utenti del mio codice?)

  2. Che lo Unit Test dovrebbe aiutarmi a scoprire le condizioni what if a cui forse non avevo ancora pensato.(Come rendere il mio codice stabile e robusto?)

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

Dipende molto dalla tua applicazione.Ad esempio, alcune applicazioni sono costituite principalmente da codice GUI che non può essere sottoposto a test unitario.

Non penso che possa esistere una regola del bianco e nero del genere.
Il codice dovrebbe essere rivisto, con particolare attenzione ai dettagli critici.
Tuttavia, se non è stato testato, contiene un bug!

Risposta breve:60-80%

Risposta lunga:Penso che dipenda totalmente dalla natura del tuo progetto.Di solito inizio un progetto testando unitariamente ogni pezzo pratico.Al primo "rilascio" del progetto dovresti avere una percentuale base abbastanza buona in base al tipo di programmazione che stai facendo.A quel punto puoi iniziare a "applicare" una copertura minima del codice.

A seconda della criticità del codice, una buona regola pratica è compresa tra il 75% e l'85%.Il codice di spedizione dovrebbe sicuramente essere testato in modo più approfondito rispetto alle utenze interne, ecc.

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

Se sei impegnato nello sviluppo da un po' e hai già molto codice implementato e ti stai rendendo conto solo ora che devi pensare alla copertura del codice, allora devi controllare la copertura attuale (se esiste) e quindi utilizzare quella base di riferimento per fissare traguardi in ogni sprint (o un aumento medio durante un periodo di sprint), il che significa assumersi il debito del codice continuando a fornire valore all'utente finale (almeno nella mia esperienza all'utente finale non importa se hai aumentato il test copertura se non vedono nuove funzionalità).

A seconda del tuo dominio, non è irragionevole puntare al 95%, ma devo dire che in media osserverai un caso medio compreso tra l'85% e il 90%.

Penso che il miglior sintomo di una corretta copertura del codice sia che la quantità di problemi concreti che i test unitari aiutano a risolvere corrisponde ragionevolmente alla dimensione del codice dei test unitari creato.

Penso che ciò che più conta sia sapere qual è l'andamento della copertura nel tempo e comprendere le ragioni dei cambiamenti di tendenza.Se consideri i cambiamenti nel trend come positivi o negativi dipenderà dalla tua analisi del motivo.

Fino a pochi giorni fa puntavamo a >80%, ma dopo aver utilizzato molto codice generato, non ci interessa la percentuale di età, ma piuttosto facciamo sì che il revisore chiami sulla copertura richiesta.

Dal post di Testivus penso che il contesto della risposta dovrebbe essere il secondo programmatore.Detto questo dal punto di vista pratico abbiamo bisogno di parametri/obiettivi a cui tendere.Ritengo che questo possa essere "testato" in un processo Agile analizzando il codice, disponiamo dell'architettura, della funzionalità (storie degli utenti) e quindi ottenendo un numero.In base alla mia esperienza nel settore Telecom direi che il 60% è un buon valore da verificare.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top