Qualsiasi strumento / suggerimento su come rifiutare l'argomento sulla qualità della copertura del codice

Nella mia esperienza, la copertura del codice è utile quanto la si rende . Se scrivi buoni test che coprono tutti i tuoi casi, il superamento di tali test significa che hai soddisfatto i tuoi requisiti. In effetti, questa è l'idea esatta che utilizza lo sviluppo Test Driven . Scrivi i test prima del codice senza sapere nulla dell'implementazione (a volte questo significa che un altro team scrive interamente i test). Questi test sono impostati per verificare che il prodotto finale esegua tutto ciò che le tue specifiche dicono di aver fatto e THEN tu scrivi il codice minimo per passare quei test.

Il problema qui, ovviamente, è che se i tuoi test non sono abbastanza forti, perderai casi limite o problemi imprevisti e scrivi codice che non soddisfa le tue specifiche. Se hai veramente intenzione di usare i test per verificare il tuo codice, allora scrivere dei buoni test è una necessità assoluta, o stai davvero perdendo tempo.

Volevo modificare la risposta qui in quanto mi sono reso conto che non rispondeva veramente alla tua domanda. Vorrei vedere questo articolo wiki per vedere alcuni benefici dichiarati di TDD. Dipende davvero dal modo in cui la tua organizzazione funziona meglio, ma TDD è sicuramente qualcosa in uso nel settore.

Prima di tutto, le persone fanno sostengono una copertura del 100%:

Most developers view ... "100% statement coverage" as adequate. This is a good start, but hardly sufficient. A better coverage standard id to meet what's called "100% branch coverage," ...

Steve McConnell, Codice completo , Capitolo 22: Test degli sviluppatori.

Come tu e altri avete già menzionato, la copertura del codice per il solo scopo di copertura non è in grado di ottenere risultati soddisfacenti. Ma se non riesci a far eseguire una riga di codice, perché è scritta?

Suggerirei di risolvere l'argomento raccogliendo e analizzando i dati sui propri progetti.

Per raccogliere i dati, personalmente utilizzo i seguenti strumenti:

• JaCoCo e il relativo plugin Eclipse EclEmma per misurare la copertura del codice.
• Ant script per la creazione, il test e il reporting automatici.
• Jenkins per le build continue: qualsiasi modifica nel controllo del codice sorgente attiva una build automatica
• JaCoCo Plugin per Jenkins: cattura le metriche di copertura per ogni build e le tendenze dei grafici. Permette anche la definizione di soglie di copertura per progetto che influiscono sulla salute della build.
• Bugzilla per il tracciamento dei bug.

Una volta che hai (o qualcosa di simile) sul posto, puoi iniziare a guardare più da vicino i tuoi dati:

• ci sono più bug trovati in progetti scarsamente coperti?
• ci sono più bug trovati in classi / metodi scarsamente coperti?
• ecc.

Mi aspetto che i tuoi dati possano supportare la tua posizione sulla copertura del codice; questa è stata certamente la mia esperienza. In caso contrario, allora forse la tua organizzazione può avere successo con standard di copertura del codice più bassi di quanto desideri. O forse i tuoi test non sono molto buoni. Si spera che il compito si concentri sulla produzione di software con meno difetti, indipendentemente dalla risoluzione del disaccordo sulla copertura del codice.

The argument from these folks is - the team would react by quickly creating low quality tests and thus waste time while adding no significant quality.

Questo è un problema di fiducia , non strumenti .

Chiedete loro perché, se credono davvero in questa affermazione, si fiderebbero del team per scrivere un codice qualsiasi?

Ok, maybe I projected it a bit too dramatically, but you get the point. The problem is about setting processes/policies in general across all teams in a homogeneous/consistent fashion.

Penso che sia il problema. Gli sviluppatori non si preoccupano (e spesso per ragioni eccellenti) di politiche coerenti o globali e vogliono la libertà di fare ciò che ritengono giusto piuttosto che conformarsi alle politiche aziendali.

Il che è ragionevole a meno che non proviate che i processi e le misure globali hanno valore e un effetto positivo sulla qualità e sulla velocità di sviluppo.

Linea temporale usuale:

1. dev: hey, guarda - Ho aggiunto le metriche di copertura del codice alla nostra dashboard, non è eccezionale?
2. manager: certo, aggiungiamo obiettivi e conformità obbligatori su quelli
3. dev: non importa, la copertura del codice è stupida e inutile, lascialo cadere

Nella mia esperienza, ci sono alcune cose da combinare con la copertura del codice per rendere la metrica utile:

Recensioni del codice

Se riesci a restituire test errati allo sviluppatore, può aiutare a limitare il numero di test non validi che forniscono questa copertura senza senso.

Monitoraggio dei bug

Se hai un sacco di copertura del codice su un modulo, ma ottieni ancora molti / gravi bug in quell'area, allora potrebbe indicare un problema in cui lo sviluppatore ha bisogno di miglioramenti con i suoi test.

Il pragmatismo

Nessuno riuscirà a raggiungere il 100% con buoni test su codice non banale. Se sei il capo della squadra, guarda la copertura del codice, ma invece di dire "dobbiamo arrivare a N%!" identifica le lacune e chiedi alle persone di "migliorare la copertura nel modulo X" che raggiunge il tuo obiettivo senza fornire alle persone l'opportunità di giocare al sistema.

Blocchi coperti / N. di test

La maggior parte degli strumenti di copertura del codice elenca i blocchi coperti rispetto ai blocchi non coperti. La combinazione di questo con il numero di test effettivi consente di ottenere una metrica che indica come i test "ampi" sono indicativi di test errati o design accoppiato. Questo è più utile come delta da uno sprint all'altro, ma l'idea è la stessa: combina la copertura del codice con altre metriche per ottenere maggiori informazioni.

Ecco i miei 2 centesimi.

Ci sono molte pratiche che hanno ricevuto molta attenzione di recente perché possono portare benefici allo sviluppo del software. Tuttavia, alcuni sviluppatori applicano queste pratiche alla cieca: sono convinti che applicare una metodologia è come eseguire un algoritmo e che dopo aver eseguito i passaggi corretti si dovrebbe ottenere il risultato desiderato.

Alcuni esempi:

• Scrivi test unitari con copertura del 100% del codice e otterrai una migliore qualità del codice.
• Applica TDD sistematicamente e otterrai un design migliore.
• Esegui la programmazione della coppia e migliorerai la qualità del codice e riduci i tempi di sviluppo.

Penso che il problema di base delle affermazioni precedenti sia che gli umani non sono computer e che scrivere software non è come eseguire un algoritmo.

Quindi, le dichiarazioni di cui sopra contengono alcune verità, ma semplificano un po 'troppo le cose, ad esempio:

• I test unitari catturano molti errori e la copertura del codice indica quali parti del codice sono testate, ma testare cose banali è inutile. Ad esempio, se facendo clic su un pulsante si apre la finestra di dialogo corrispondente, l'intera logica che invia l'evento del pulsante al componente che apre la finestra di dialogo può essere verificata con un semplice test manuale (fare clic sul pulsante): ripaga all'unità prova questa logica?
• Sebbene TDD sia un buon strumento di progettazione, non funziona bene se lo sviluppatore ha una scarsa comprensione del dominio del problema (vedi ad esempio questo famoso post ).
• La programmazione accoppiata è efficace se due sviluppatori possono lavorare insieme, altrimenti è un disastro. Inoltre, gli sviluppatori esperti potrebbero preferire di discutere brevemente i problemi più importanti e quindi codificarli separatamente: trascorrendo molte ore a discutere di molti dettagli che entrambi sanno già possono essere sia noiosi che una grande perdita di tempo.

Ritorno alla copertura del codice.

I have been able to push back by selling the argument that Code Coverage tells me what has not been tested for sure and help us focus on those areas.

Penso che devi giudicare da caso a caso se vale la pena avere una copertura del 100% per un determinato modulo.

Il modulo esegue calcoli molto importanti e complicati? Quindi vorrei testare ogni singola riga di codice, ma anche scrivere test unitari significativi (test unitari che hanno senso in quel dominio).

Il modulo esegue alcune attività importanti ma semplici come aprire una finestra di aiuto quando si fa clic su un pulsante? Un test manuale sarà probabilmente più efficace.

The argument from these folks is - then team would react by quickly creating low quality tests and thus waste time while adding no significant quality.

Secondo me hanno ragione: non puoi imporre la qualità del codice con solo che richiede copertura del 100% del codice. Aggiungere altri strumenti per calcolare la copertura e fare statistiche non aiuterà. Piuttosto, dovresti discutere quali parti del codice sono più sensibili e dovrebbero essere testate estesamente e quali sono meno soggette a errori (nel senso che un errore può essere scoperto e risolto molto più facilmente senza usare i test unitari).

Se si spinge la copertura del codice al 100% sugli sviluppatori, alcuni inizieranno a scrivere test di unità sciocchi per adempiere ai propri obblighi invece di provare a scrivere test sensibili.

how do you allocate guaranteed time without having any measure to it

Forse è un'illusione che tu possa misurare l'intelligenza e il giudizio umani. Se hai colleghi competenti e hai fiducia nel loro giudizio, puoi farlo accetta quando ti dicono "per questo modulo, l'aumento della copertura del codice porterà pochissimi benefici, quindi non passarci il tempo" o, "per questo modulo abbiamo bisogno di tutta la copertura che possiamo ottenere, abbiamo bisogno di una settimana in più per implementare test di unità sensibili. ".

Quindi (ancora, questi sono i miei 2 centesimi): non cercare di trovare un processo e impostare parametri come la copertura del codice che deve andare bene per tutti i team, per tutti i progetti e per tutti i moduli. Trovare un simile processo generale è un'illusione e credo che quando ne avrai trovato uno sarà subottimale.

"il team reagirebbe creando rapidamente test di bassa qualità e quindi sprecando tempo senza aggiungere una qualità significativa"

Questo è un rischio reale, non solo teorico.

Il solo eccesso di codice è una metrica disfunzionale. Ho imparato quella lezione nel modo più duro. Una volta, l'ho enfatizzato senza la disponibilità di bilanciare metriche o pratiche. Centinaia di test che catturano e mascherano le eccezioni, e senza affermazioni è una cosa brutta.

"suggerimento per una combinazione di tali strumenti di copertura del codice e pratiche / processi per accompagnarli"

Oltre a tutti gli altri suggerimenti, esiste una tecnica di automazione in grado di valutare la qualità dei test: test di mutazione ( link ). Per il codice Java, il PIT ( link ) funziona ed è il primo strumento di test sulle mutazioni a cui mi sono imbattuto.

Come si nota, la mancanza di copertura del codice è prontamente identificabile come rischio di qualità del software. Insegno che la copertura del codice è una condizione necessaria, ma insufficiente per la qualità del software. Dobbiamo adottare un approccio bilanciato alla gestione della qualità del software.

La copertura del codice non è certamente una prova di buoni test unitari, in quanto corretti.

Ma a meno che non siano in grado di fornire un modo per dimostrare che tutti i test unitari sono buoni (per qualsiasi definizione di bene possano venire fuori), allora questo è davvero un punto di silenzio.

Ho sempre trovato che la copertura del codice è facilmente suscettibile all'effetto Hawthorne . Questo mi ha fatto chiedere "perché abbiamo qualche metrica del software?" e la risposta di solito è di fornire una comprensione ad alto livello dello stato attuale del progetto, ad esempio:

"quanto siamo vicini a fare?"

"qual è la qualità di questo sistema?"

"Quanto sono complicati questi moduli?"

Ahimè, non ci sarà mai una singola metrica in grado di dirti quanto è buono o cattivo il progetto, e qualsiasi tentativo di derivare quel significato da un singolo numero necessariamente semplificherà. Mentre le metriche sono tutte relative ai dati, interpretare ciò che intendono è un compito molto più emotivo / psicologico e come tale probabilmente non può essere applicato in modo generico a gruppi di diversa composizione o problemi di domini diversi.

Nel caso della copertura, penso che sia spesso usato come proxy per la qualità del codice, albiet piuttosto grezzo. E il vero problema è che si riduce un argomento terribilmente complicato a un singolo intero compreso tra 0 e 100 che verrà ovviamente utilizzato per indirizzare il lavoro potenzialmente inutile in una ricerca senza fine per ottenere una copertura del 100%. Gente come Bob Martin dirà che il 100% di copertura è l'unico obiettivo serio, e posso capire perché sia così, perché qualsiasi altra cosa sembra arbitraria.

Naturalmente ci sono molti modi per ottenere una copertura che in realtà non mi aiuta a capire la base di codice - ad es. è prezioso testare toString ()? che dire di getter e setter per oggetti immutabili? Una squadra ha tanto impegno da applicare in un tempo prefissato e quel tempo sembra sempre meno del tempo richiesto per fare un lavoro perfetto, quindi in assenza di un programma perfetto dobbiamo accontentarci delle approssimazioni.

Una metrica che ho trovato utile per fare buone approssimazioni è Crap4J . Ora è defunto ma puoi facilmente portarlo / implementarlo da solo. Crap4J tenta di collegare la copertura del codice alla complessità ciclomatica implicando che il codice che è più complicato (ifs, whiles, fors ecc.) Dovrebbe avere una copertura di test più alta. Per me questa semplice idea ha davvero suonato vero. Voglio capire dove c'è il rischio nella mia base di codice, e un rischio veramente importante è la complessità. Quindi, utilizzando questo strumento, posso valutare rapidamente quanto sia rischiosa la mia base di codice. Se è complicato, la copertura dovrebbe andare meglio. Se non lo è, non ho bisogno di perdere tempo a cercare di coprire ogni linea di codice.

Ovviamente questa è una sola metrica e YMMV. Devi dedicare del tempo per capire se ha senso per te e se darà alla tua squadra una sensazione ragionevole di dove si trova il progetto.

Non direi che tornare indietro e coprire il codice esistente è il miglior percorso da seguire. Direi che ha senso scrivere test di copertura per ogni nuovo codice che scrivi e o qualsiasi codice che cambi.

Quando vengono trovati bug, scrivi un test che fallisce a causa di quel bug e correggi il bug in modo che il test diventi verde. Inserisci nei commenti del test per quale bug è stato scritto.

L'obiettivo è avere sufficiente sicurezza nei test per poter apportare modifiche senza preoccuparsi di effetti collaterali imprevisti. Scopri come funziona efficacemente con il codice legacy per un buon riepilogo degli approcci al codice non verificato della domotica.