È fattibile attendersi una copertura del 100% del codice in applicazioni web jquery / backbonejs pesanti? È ragionevole fallire uno sprint a causa della mancata copertura del 100% quando la copertura del codice reale si aggira intorno al 92% -95% in javascript / jquery?
È ugualmente realistico in quanto non realistico.
Realistici
Se hai eseguito test automatici che hanno dimostrato di coprire l'intera base di codice, è ragionevole insistere sulla copertura del 100%.
Dipende anche da quanto è critico il progetto. Quanto più è critico, tanto più ragionevole aspettarsi / richiedere una copertura completa del codice.
È più facile farlo per progetti di dimensioni medio-piccole.
Unrealistic
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 lì.
Ho lavorato a una gamma di progetti che vanno da nessuna copertura a decente. Mai un progetto con il 100%, ma c'erano certamente delle volte in cui avrei voluto avere una copertura più vicina al 100%.
In definitiva, la domanda è se la copertura esistente soddisfa abbastanza dei casi necessari perché il team si senta a proprio agio nella spedizione del prodotto.
Non conosciamo l'impatto di un errore sul tuo progetto, quindi non possiamo dire se il 92% o il 95% è sufficiente, o se il 100% è realmente richiesto. Oppure, per il resto, il 100% controlla completamente tutto ciò che ti aspetti.
È molto ingenuo al meglio e non realistico anche in senso teorico e impraticabile in senso commerciale.
È molto costoso scrivere test, è un codice che deve essere scritto e testato da solo, è un codice che deve essere documentato in ciò che effettivamente prova per testare, è il codice che deve essere mantenuto con il business le modifiche logiche e i test falliscono perché non sono aggiornati. Mantenere 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 di integrazione non siano utili, ma solo dove hanno senso, e al di fuori delle industrie che possono uccidere persone non ha senso provare e testare ogni linea di codice in un codice base. Al di fuori di queste uccisioni cruciali molte persone calcolano rapidamente le basi di codice, è impossibile calcolare un ritorno sull'investimento positivo che implicherebbe una copertura del 100% del codice.
In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running or continue to run forever.
Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. A key part of the proof was a mathematical definition of a computer and program, which became known as a Turing machine; the halting problem is undecidable over Turing machines. It is one of the first examples of a decision problem.
Dal momento che non puoi nemmeno provare che qualcosa funziona al 100% perché farlo diventare il tuo obiettivo?
Nella maggior parte dei casi, la copertura del codice al 100% significa che hai "barato" un po ':
Fondamentalmente, le parti difficili da testare sono state deviate in aree in cui non sono necessariamente considerate "codice". Non è sempre realistico, ma tieni presente che, indipendentemente dall'aiutarti a testare, tutte queste pratiche ti aiutano a semplificare il lavoro sul codice base.
Per un esempio impressionante e realistico di copertura del 100% delle filiali , vedi Come viene testato SQLite .
Mi rendo conto che la tua domanda riguarda specificamente JavaScript, che è un tipo completamente diverso di prodotto software, ma voglio portare consapevolezza a ciò che può essere fatto con una motivazione sufficiente.
Il 100% di copertura del codice per i test unitari per tutti i pezzi di una particolare applicazione è un sogno irrealizzabile, anche con nuovi progetti. Vorrei che fosse così, ma a volte non riesci a coprire un pezzo di codice, non importa quanto tu cerchi di astrarre le dipendenze esterne. Ad esempio, supponiamo che il tuo codice debba richiamare un servizio web. È possibile nascondere le chiamate al servizio Web dietro un'interfaccia in modo da poter prendere in giro quel pezzo e testare la logica di business prima e dopo il servizio web. Ma il pezzo reale che ha bisogno di invocare il servizio web non può essere testato unitamente (molto bene comunque). Un altro esempio è se è necessario connettersi a un server TCP. È possibile nascondere il codice che si connette a un server TCP dietro un'interfaccia. Ma il codice che si connette fisicamente a un server TCP non può essere testato unitamente, perché se per qualche motivo non funziona, il test dell'unità fallirà. E i test unitari devono sempre passare, indipendentemente da quando vengono richiamati.
Una buona regola empirica è che tutta la logica aziendale dovrebbe avere una copertura del 100% del codice. Ma i pezzi che devono richiamare componenti esterni dovrebbero avere una copertura del codice più vicina al 100% possibile. 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 la copertura del codice solo per avere la 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 stato progettato con l'obiettivo specifico di consentire una copertura del 100%, il 100% potrebbe non essere possibile. Uno dei motivi potrebbe essere che se si codifica in modo difensivo - cosa che si dovrebbe - a volte si dovrebbe avere un codice che gestisce situazioni che non si dovrebbero verificare o che potrebbero non accadere in base alla propria conoscenza del sistema. Coprire tale codice con i test sarebbe molto difficile per definizione. Non avere questo codice può essere pericoloso - cosa succede se ti sbagli e questa situazione avviene una volta su 256 ? Che cosa succede se c'è un cambiamento nel luogo non correlato che rende possibile la cosa impossibile? Ecc. Quindi il 100% può essere piuttosto difficile da raggiungere con mezzi "naturali" - ad esempio, se hai un codice che alloca la memoria e hai un codice che controlla se ha fallito, a meno che non prendi in giro il gestore della memoria (che potrebbe non essere facile) e scrivere un test che restituisce "memoria esaurita", che copre quel codice potrebbe essere difficile. Per l'applicazione JS, potrebbe essere una codifica difensiva attorno a possibili stranezze del DOM in diversi browser, possibili errori di servizi esterni, ecc.
Quindi direi che uno dovrebbe cercare di essere il più vicino al 100% possibile e avere una buona ragione per il delta, ma non vedrei proprio il 100% come errore. Il 95% può andare bene per un grande progetto, a seconda di cosa sia il 5%.
Se stai iniziando con un nuovo progetto e stai utilizzando rigorosamente una metodologia di test-first, è del tutto ragionevole avere una copertura del 100% del codice nel senso che tutto il tuo codice sarà invocato ad un certo punto quando i tuoi test sono stati eseguiti 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 provato alcuni metodi anche indirettamente.
Ottenere il 100% del codice testato è potenzialmente un esercizio costoso, in particolare se non hai progettato il tuo sistema per permetterti di raggiungere questo obiettivo, e se stai concentrando i tuoi sforzi di progettazione sulla testabilità, probabilmente non stai dando abbastanza della vostra attenzione a progettare la vostra applicazione per soddisfare le sue esigenze specifiche, in particolare dove il progetto è grande. Mi dispiace, ma semplicemente non puoi avere entrambe le cose senza che qualcosa venga compromesso.
Se stai introducendo test su un progetto esistente in cui il test non è stato mantenuto o incluso prima, allora è impossibile ottenere una copertura del codice del 100% senza che i costi dell'esercizio superino lo sforzo. Il meglio che puoi sperare è quello di fornire una copertura di test per le sezioni critiche del codice che sono chiamate più.
Is it reasonable to fail a sprint due to 100% coverage not being met when actual code coverage hovers around 92%-95% in javascript/jquery?
Nella maggior parte dei casi, direi che dovresti solo considerare il tuo sprint di avere "fallito" se non hai raggiunto i tuoi obiettivi. In realtà, preferisco non pensare agli sprint come falliti in questi casi, perché devi essere in grado di imparare dagli sprint che non soddisfano le aspettative al fine di ottenere la pianificazione giusta la prossima volta che definisci uno sprint. Indipendentemente da ciò, non penso sia ragionevole considerare che la copertura del codice sia un fattore del successo relativo di uno sprint. Il tuo obiettivo dovrebbe essere quello di fare quanto basta per far funzionare tutto come specificato, e se stai programmando prima il test, allora dovresti essere sicuro che i tuoi test supporteranno questo obiettivo. Qualsiasi altro test che ritieni possa essere necessario aggiungere è un rivestimento a base di zucchero e quindi una spesa aggiuntiva che può aiutarti a completare i tuoi sprint in modo soddisfacente.
Non lo faccio naturalmente, ma l'ho fatto su due grandi progetti. Se hai comunque un framework per il test delle unità, non è difficile esattamente, ma si sommano a molti test.
C'è qualche ostacolo particolare che stai incontrando che ti impedisce di colpire quelle ultime poche righe? In caso contrario, se ottenere una copertura dal 95% al 100% è semplice, quindi potresti anche farlo. Dato che stai chiedendo qui, assumerò che è qualcosa. Cos'è questo?
Il 92% va bene. Sento che le vere domande sono:
Il 92% è la "nuova" norma ora? Se il prossimo sprint ha l'88% di test, 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 il gusto di testare"
Esiste un piano per tornare indietro e compilare i test mancanti?
Perché stai provando? Sembra che lo stato attivo sia% della linea coperta e non funzionalità
Martin Fowler scrive in il 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, esistono anche standard che impongono una copertura del 100% a livello di unità. Ad esempio, è uno dei requisiti negli standard della comunità europea di volo spaziale (ECSS, European Cooperation for Space Standardization). Il documento collegato qui , racconta una storia interessante del progetto che aveva l'obiettivo di raggiungere il 100% di copertura di prova in un software già completato . Si basa su nterviews con gli ingegneri coinvolti che hanno sviluppato i test unitari.
Alcune delle lezioni sono:
Forse chiedere se è fattibile e ragionevole non sono le domande più utili da porre. Probabilmente la risposta più pratica è quella accettata. Lo analizzerò a un livello più filosofico.
La copertura al 100% sarebbe l'ideale, ma idealmente, non sarebbe necessaria, o sarebbe molto più facile da ottenere. 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 codice che sia completamente corretto e che non abbia bug. Non è naturale. Quindi, senza altra opzione ovvia, ci rivolgiamo a tecniche come TDD e copertura del codice di tracciamento. Ma finché il risultato finale è ancora un processo innaturale, avrai difficoltà a convincere le persone a farlo in modo coerente e felice.
Raggiungere una copertura del 100% del codice è un atto innaturale. Per la maggior parte delle persone, costringerli a raggiungerlo sarebbe una forma di tortura.
Abbiamo bisogno di processi, strumenti, linguaggi e codici che si adattino ai nostri modelli mentali naturali. Se non lo facciamo, non c'è modo di testare la qualità in un prodotto.
Guarda tutti i software là fuori oggi. La maggior parte di questi incasina abbastanza regolarmente. Non vogliamo crederci. Vogliamo credere che la nostra tecnologia sia magica e ci renda felici. Quindi 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 là fuori oggi è piuttosto schifoso.
Ecco alcuni sforzi per rendere la codifica più naturale:
Il successivo è estremamente incompleto e sperimentale. In realtà è un progetto che ho iniziato, ma credo che sarebbe un enorme passo in avanti per il mestiere di programmazione se potessi mai mettermi il tempo per completarlo. Fondamentalmente è l'idea che se i contratti esprimono gli unici aspetti di un comportamento delle classi a cui teniamo, e stiamo già esprimendo contratti come codice, perché non solo hanno 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 fattibile e se stai praticando il TDD probabilmente lo colpirai di default poiché stai deliberatamente scrivendo test per ogni linea di codice di produzione.
Sul codice legacy esistente che è stato scritto senza test unitari, può essere difficile, poiché spesso il codice legacy non è stato scritto pensando ai test unitari e può richiedere un sacco di refactoring. Quel livello di refactoring spesso non è pratico, date le realtà del rischio e del programma, in modo da fare trade off.
Nel mio team ho specificato una copertura del 100% del codice e se vediamo meno di questo nella revisione del codice, il proprietario tecnico del componente spiega perché il 100% non è stato raggiunto con lo sviluppatore e deve concordare con il ragionamento dello sviluppatore. Spesso, se si verifica un problema al 100%, lo sviluppatore parlerà con il proprietario tecnico prima della revisione del codice. Abbiamo scoperto che una volta che hai preso l'abitudine e apprendi le tecniche per lavorare su diversi problemi comuni con l'aggiunta di test al codice precedente che colpiscono regolarmente il 100% non è così difficile come pensavi inizialmente.
Il libro di Michael Feather " Lavorare efficacemente con il codice legacy " è stato per noi prezioso per elaborare strategie per aggiungendo 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 testare una funzione che ha preso due interi a 64 bit e li ha moltiplicati? Questo è sempre stato il mio problema con i test rispetto a provare un programma corretto. Per qualsiasi cosa tranne i programmi più banali, il test è fondamentalmente inutile in quanto copre solo un numero limitato di casi. È come controllare 1.000 numeri e dire che hai dimostrato la congettura di Goldbach.
Leggi altre domande sui tag tdd bdd code-quality