La copertura del codice al 100% è un sogno irrealizzabile?

È possibile aspettarsi una copertura del codice del 100% nelle applicazioni Web pesanti jquery / backbonejs? È ragionevole fallire uno sprint a causa della mancata copertura del 100% quando la copertura del codice attuale si aggira intorno al 92% -95% in javascript / jquery?

È ugualmente realistico in quanto non realistico.

Realistico
Se si dispone di test automatici che hanno dimostrato di coprire l'intera base di codice, è ragionevole insistere sulla copertura del 100%.
Dipende anche da quanto sia critico il progetto. Più è critico, più è ragionevole aspettarsi / richiedere una copertura completa del codice.
È più facile farlo per progetti di dimensioni medio-piccole.

Non realistico Stai iniziando con una copertura dello 0% ...
Il progetto è mostruoso con molti, molti percorsi di errore che sono difficili da ricreare o innescare.
La direzione non è disposta a impegnarsi / investire per assicurarsi che la copertura sia presente.

Ho lavorato su una gamma di progetti che vanno da nessuna copertura a decente. Mai un progetto con il 100%, ma ci sono state certamente delle volte in cui avrei voluto avere una copertura più vicina al 100%.
In definitiva la domanda è se la copertura esistente soddisfa abbastanza i casi richiesti per consentire al team di sentirsi a proprio agio nella spedizione del prodotto.

Non conosciamo l'impatto di un fallimento sul tuo progetto, quindi non possiamo dire se il 92% o il 95% è sufficiente o se quel 100% è realmente necessario. O del resto, il 100% testa completamente tutto ciò che ti aspetti.

Chi mette alla prova le prove?

Nella migliore delle ipotesi è molto ingenuo e irrealistico anche in senso teorico e poco pratico in senso commerciale.

• Non è realistico con un codice che presenta un'elevata complessità ciclomatica. Ci sono troppe variabili per coprire ogni combinazione.
• Non è realistico con un codice fortemente concorrente. Il codice non è deterministico, quindi non è possibile coprire tutte le condizioni che potrebbero verificarsi perché il comportamento cambierà ad ogni esecuzione del test.
• Non è realistico in senso commerciale, paga davvero dividendi per scrivere test per codice che è un codice di percorso critico, che è un codice importante e un codice che può cambiare frequentemente.

Testare ogni riga di codice non è un buon obiettivo

Scrivere test è molto costoso, è il codice che deve essere scritto e testato da solo, è il codice che deve essere documentato in ciò che sta effettivamente cercando di testare, è il codice che deve essere mantenuto con le modifiche della logica aziendale e i test falliscono perché non sono aggiornati. Mantenere i test automatici e la documentazione su di essi può essere più costoso che mantenere il codice a volte.

Questo non vuol dire che i test unitari e i test di integrazione non siano utili, ma solo dove hanno senso, e al di fuori dei settori che possono uccidere le persone non ha senso provare a testare ogni riga di codice in una base di codice. Al di fuori di queste critiche uccisioni molte persone codificano rapidamente le basi, è impossibile calcolare un ritorno sugli investimenti positivo che comporterebbe una copertura del codice del 100%.

Arresto del problema:

Nella teoria della computabilità, il problema dell'arresto è il problema di determinare, da una descrizione di un programma informatico arbitrario e un input, se il programma finirà di funzionare o continuerà a funzionare per sempre.

Nel 1936 Alan Turing dimostrò che non poteva esistere un algoritmo generale per risolvere il problema di arresto per tutte le possibili coppie input-programma. Una parte fondamentale della dimostrazione era una definizione matematica di un computer e un programma, che divenne noto come una macchina di Turing; il problema dell'arresto è indecidibile rispetto alle macchine di Turing. È uno dei primi esempi di un problema decisionale.

Dal momento che non puoi nemmeno provare che qualcosa funzioni al 100%, perché realizzare questo obiettivo?

Chiaro e semplice, nella maggior parte dei casi non ha alcun senso commerciale.

Nella maggior parte dei casi, la copertura del codice al 100% significa che hai "tradito" un po ':

• Parti complesse e che cambiano frequentemente del sistema (come la GUI) sono state spostate in modelli dichiarativi o altri DSL.
• Tutto il codice che tocca i sistemi esterni è stato isolato o gestito dalle librerie.
• Lo stesso vale per qualsiasi altra dipendenza, in particolare quelli che richiedono effetti collaterali.

Fondamentalmente, le parti difficili da testare sono state deviate verso aree in cui non vengono necessariamente considerate "codice". Non è sempre realistico, ma nota che indipendentemente dall'aiutarti a testare, tutte queste pratiche rendono il tuo codebase più semplice su cui lavorare.

Per un esempio impressionante e reale della copertura delle filiali al 100% , vedere Come viene testato SQLite .

Mi rendo conto che la tua domanda si rivolge specificamente a javascript che è un tipo di prodotto software completamente diverso, ma voglio sensibilizzare su ciò che può essere fatto con sufficiente motivazione.

La copertura del codice al 100% per i test unitari per tutti i pezzi di una particolare applicazione è un sogno irrealizzabile, anche con nuovi progetti. Vorrei che fosse il caso, ma a volte non riesci proprio a coprire un pezzo di codice, non importa quanto tu provi a sottrarre dipendenze esterne. Ad esempio, supponiamo che il tuo codice debba invocare un servizio web. È possibile nascondere le chiamate del servizio Web dietro un'interfaccia in modo da poter deridere quel pezzo e testare la logica aziendale prima e dopo il servizio Web. Ma il pezzo reale che deve invocare il servizio web non può essere testato in unità (comunque molto bene). Un altro esempio è se è necessario connettersi a un server TCP. È possibile nascondere il codice che si collega a un server TCP dietro un'interfaccia. Ma il codice che si connette fisicamente a un server TCP non può essere testato dall'unità, perché se è inattivo per qualsiasi motivo, ciò provocherebbe il fallimento del test unitario. E i test unitari devono sempre superare, indipendentemente da quando vengono invocati.

Una buona regola empirica è che tutta la tua logica aziendale dovrebbe avere una copertura del codice del 100%. Ma i pezzi che devono invocare componenti esterni, dovrebbero avere una copertura del codice il più vicino possibile al 100%. Se non riesci a raggiungerlo, non lo suderei troppo.

Molto più importante, i test sono corretti? Riflettono accuratamente la tua attività e i requisiti? Avere una copertura del codice solo per avere una copertura del codice non significa nulla se tutto ciò che fai è testare in modo errato o testare un codice errato. Detto questo, se i tuoi test sono buoni, avere una copertura del 92-95% è eccezionale.

Direi che a meno che il codice non sia progettato con l'obiettivo specifico di consentire la copertura del test al 100%, il 100% potrebbe non essere realizzabile. Uno dei motivi sarebbe che se codifichi in modo difensivo - cosa che dovresti - a volte dovresti avere un codice che gestisca situazioni che sei sicuro che non dovrebbero accadere o che non potrebbero accadere data la tua conoscenza del sistema. Coprire tale codice con i test sarebbe molto difficile per definizione. Non avere tale codice può essere pericoloso - cosa succede se ti sbagli e questa situazione si verifica una volta su 256? E se ci fosse un cambiamento in un luogo non correlato che rende possibile una cosa impossibile? Ecc. Quindi il 100% può essere piuttosto difficile da raggiungere con mezzi "naturali" - ad esempio, se si dispone di codice che alloca memoria e si dispone di codice che controlla se non ha funzionato, a meno che non si derida il gestore della memoria (che potrebbe non essere facile) e scrivere un test che ritorna "memoria insufficiente", coprendo quel codice potrebbe essere difficile. Per l'applicazione JS, può essere una codifica difensiva attorno a possibili stranezze DOM in diversi browser, possibili guasti di servizi esterni, ecc.

Quindi direi che uno dovrebbe lottare per essere il più vicino al 100% possibile e avere una buona ragione per il delta, ma non vedrei che non ottenere esattamente il 100% come necessariamente fallimento. Il 95% può andare bene su un grande progetto, a seconda di quale sia il 5%.

Se stai iniziando con un nuovo progetto e stai utilizzando rigorosamente una metodologia test-first, è del tutto ragionevole avere una copertura del codice del 100%, nel senso che tutto il tuo codice verrà invocato ad un certo punto quando i tuoi test hanno stato eseguito. Tuttavia, potresti non aver testato esplicitamente ogni singolo metodo o algoritmo direttamente a causa della visibilità del metodo e in alcuni casi potresti non aver testato alcuni metodi nemmeno indirettamente.

Ottenere il 100% del tuo codice testato è potenzialmente un esercizio costoso, in particolare se non hai progettato il tuo sistema per consentirti di raggiungere questo obiettivo e se stai concentrando i tuoi sforzi di progettazione sulla testabilità, probabilmente non stai dando abbastanza attenzione a progettare la tua applicazione per soddisfare i suoi requisiti specifici, in particolare laddove il progetto è di grandi dimensioni. Mi dispiace, ma semplicemente non puoi averlo in entrambi i modi senza che qualcosa venga compromesso.

Se si stanno introducendo test in un progetto esistente in cui i test non sono stati mantenuti o inclusi in precedenza, è impossibile ottenere una copertura del codice del 100% senza che i costi dell'esercizio superino lo sforzo. Il meglio che puoi sperare è di fornire una copertura di prova per le sezioni critiche di codice che vengono chiamate di più.

È ragionevole fallire uno sprint a causa della mancata copertura del 100% quando la copertura del codice attuale si aggira intorno al 92% -95% in javascript / jquery?

Nella maggior parte dei casi, direi che dovresti considerare il tuo sprint come "fallito" solo se non hai raggiunto i tuoi obiettivi. In realtà, preferisco non pensare agli sprint come un fallimento in questi casi perché devi essere in grado di imparare dagli sprint che non soddisfano le aspettative al fine di ottenere la tua pianificazione corretta la prossima volta che definisci uno sprint. Indipendentemente da ciò, non credo sia ragionevole considerare la copertura del codice come un fattore nel relativo successo di uno sprint. Il tuo obiettivo dovrebbe essere quello di fare quanto basta per far funzionare tutto come specificato, e se stai programmando il test prima, allora dovresti essere sicuro che i tuoi test supporteranno questo obiettivo. Qualsiasi test aggiuntivo che ritieni necessario aggiungere è un rivestimento di zucchero efficace e quindi una spesa aggiuntiva che può trattenerti nel completare in modo soddisfacente gli sprint.

Non lo faccio naturalmente, ma l'ho fatto su due grandi progetti. Se hai comunque un framework per i test unitari, non è esattamente difficile, ma si aggiunge a molti test.

C'è qualche ostacolo particolare che stai incontrando che ti impedisce di colpire quelle ultime righe? In caso contrario, se ottenere una copertura dal 95% al ​​100% è semplice, quindi potresti anche farlo. Dato che stai chiedendo qui, suppongo che ci sia qualcosa. Cos'è quel qualcosa?

Il 92% va bene. Sento che le vere domande sono:

• Il 92% è ormai la "nuova" norma? Se il prossimo sprint prevede un test dell'88%, andrà bene? Questo è spesso l'inizio dell'abbandono delle suite di test.

• Quanto è importante che il software funzioni e non abbia bug. Hai dei test per questi motivi, non "per motivi di test"

• C'è un piano per tornare indietro e compilare i test mancanti?

• Perché stai testando? Sembra che il focus sia% della linea coperta e non funzionalità

Martin Fowler scrive nel suo blog :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

Tuttavia, ci sono persino standard che impongono una copertura del 100% a livello di unità. Ad esempio, è uno dei requisiti degli standard della comunità europea dei voli spaziali (ECSS, European Cooperation for Space Standardization). Il documento collegato qui , racconta un'interessante storia di progetto che aveva l'obiettivo di raggiungere il 100% di copertura dei test in un software già completato. Si basa su interviste con gli ingegneri coinvolti che hanno sviluppato i test unitari.

Alcune delle lezioni sono:

• La copertura al 100% è insolita ma realizzabile
• Talvolta è necessaria una copertura del 100%
• Una copertura del 100% comporta nuovi rischi
• Non ottimizzare per la metrica al 100%
• Sviluppa una strategia adeguata per massimizzare la copertura
• Una copertura del 100% non è una condizione sufficiente per una buona qualità

Forse chiedere se è fattibile e ragionevole non sono le domande più utili da porre. Probabilmente la risposta più pratica è quella accettata. Analizzerò questo a un livello più filosofico.

Una copertura del 100% sarebbe l'ideale, ma idealmente non sarebbe necessaria o sarebbe molto più facile da raggiungere. Preferisco pensare se è naturale e umano che fattibile o ragionevole.

L'atto di programmare correttamente è quasi impossibile con gli strumenti di oggi. È molto difficile scrivere un codice totalmente corretto e privo di bug. Non è semplicemente naturale. Quindi, con nessuna altra opzione ovvia, passiamo a tecniche come TDD e copertura del codice di tracciamento. Ma finché il risultato finale sarà ancora un processo innaturale, avrai difficoltà a convincere le persone a farlo in modo coerente e felice.

Raggiungere il 100% di copertura del codice è un atto innaturale. Per la maggior parte delle persone, costringerli a raggiungere questo obiettivo sarebbe una forma di tortura.

Abbiamo bisogno di processi, strumenti, lingue e codice che si associno ai nostri modelli mentali naturali. Se non riusciamo a farlo, non c'è modo di testare la qualità in un prodotto.

Guarda tutti i software là fuori oggi. La maggior parte si incasina abbastanza regolarmente. Non vogliamo crederci. Vogliamo credere che la nostra tecnologia sia magica e renderci felici. E così scegliamo di ignorare, scusare e dimenticare la maggior parte delle volte che la nostra tecnologia incasina. Ma se prendiamo una valutazione onesta delle cose, la maggior parte del software oggi disponibile è piuttosto scadente.

Ecco alcuni sforzi per rendere la codifica più naturale:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

Il successivo è estremamente incompleto e sperimentale. In realtà è un progetto che ho iniziato, ma credo che sarebbe un grande passo avanti per l'arte della programmazione se potessi mai farmi dedicare del tempo per completarlo. Fondamentalmente è l'idea che se i contratti esprimono gli unici aspetti di un comportamento delle classi a cui teniamo e che stiamo già esprimendo i contratti come codice, perché non hanno solo le definizioni di classe e metodo insieme ai contratti. In questo modo i contratti sarebbero il codice e non avremmo bisogno di implementare tutti i metodi. Lascia che la biblioteca capisca come onorare i contratti per noi.

Raggiungere il 100% sul nuovo codice dovrebbe essere molto realizzabile e se stai praticando TDD probabilmente lo colpirai di default poiché stai scrivendo deliberatamente dei test per ogni linea di codice di produzione.

Su un codice legacy esistente che è stato scritto senza test unitari, può essere difficile in quanto spesso il codice legacy non è stato scritto pensando ai test unitari e può richiedere molto refactoring. Quel livello di refactoring spesso non è pratico date le realtà del rischio e il programma in modo da fare degli scambi.

Nel mio team specifico la copertura del codice al 100% e se nella revisione del codice ne vediamo di meno, il proprietario tecnico del componente discute del perché il 100% non è stato raggiunto con lo sviluppatore e deve essere d'accordo con il ragionamento dello sviluppatore. Spesso se si verifica un problema a colpire al 100%, lo sviluppatore parla con il proprietario tecnico prima della revisione del codice. Abbiamo scoperto che una volta che hai preso l'abitudine e apprendi le tecniche per aggirare diversi problemi comuni con l'aggiunta di test al codice legacy che colpire il 100% regolarmente non è così difficile come penseresti inizialmente.

Il libro di Michael Feather " Lavorare efficacemente con il codice legacy " è stato prezioso per noi per aver escogitato strategie per aggiungere test al nostro codice legacy.

No, non è possibile e non lo sarà mai. Se fosse possibile, tutta la matematica cadrebbe nel finitismo. Ad esempio, come testereste una funzione che ha preso due numeri interi a 64 bit e li ha moltiplicati? Questo è sempre stato il mio problema con i test rispetto a dimostrare che un programma è corretto. A parte i programmi più banali, i test sono praticamente inutili in quanto coprono solo un numero limitato di casi. È come controllare 1.000 numeri e dire che hai dimostrato la congettura di Goldbach.