È la copertura 100% del codice davvero una buona cosa quando si fa test di unità? [chiuso]

https://stackoverflow.com/questions/3123777

30-09-2019
|

Domanda

Ho sempre saputo che facendo la massima copertura del codice con test di unità è bene . Ho anche sentito sviluppatori di grandi aziende come Microsoft dicendo che scrivono più linee di testare il codice del codice eseguibile in sé.

Ora, è davvero grande? non sembra a volte come un completa perdita di tempo che ha un unico effetto di rendendo più difficile la manutenzione

Per esempio, diciamo che ho un metodo di DisplayBooks() che popola una lista di libri da un database. I requisiti del prodotto dicono che se ci sono più di un centinaio di libri nel negozio, deve essere visualizzato solo un centinaio .

Così, con TDD,

I partirà facendo un test BooksLimit() unità che farà risparmiare duecento libri nel database, chiamata DisplayBooks(), e fare un Assert.AreEqual(100, DisplayedBooks.Count).
Poi mi metterà alla prova se fallisce,
Poi mi cambierà DisplayBooks() impostando il limite dei risultati a 100, e
Infine io eseguire nuovamente il test per vedere se riesce.

Beh, non è molto più facile andare direttamente al terzo passo, e non mai fare test di unità BooksLimit() a tutti? E non è più agile, quando i requisiti cambiano 100-200 limite libri, per modificare un solo carattere, invece di cambiare test, l'esecuzione di test per verificare se non riesce, modificare il codice e l'esecuzione di test di nuovo per verificare se ci riesce?

Nota: lascia supporre che il codice è completamente documentato. In caso contrario, qualcuno potrebbe dire, e sarebbe giusto, che facendo test di unità piena aiuterà a capire il codice che manca di documentazione. Infatti, avere una prova di unità BooksLimit() mostrerà molto chiaramente che v'è un numero massimo di libri alla visualizzazione, e che questo numero massimo è 100. Entrando nel codice non-unità di test sarebbe molto più difficile, in quanto tale limite può essere attuato anche se for (int bookIndex = 0; bookIndex < 100; ... o foreach ... if (count >= 100) break;.

Soluzione

Beh, non è molto più facile andare direttamente al terzo passo, e non fanno mai BooksLimit) test di unità (a tutti?

Sì ... Se non si perderà nessun tempo a scrivere i test, si spenderà meno tempo a scrivere i test. Il progetto potrebbe prendere più nel complesso, perché si spenderà un sacco di tempo di debug, ma forse è più facile spiegare al tuo manager? Se questo è il caso ... ottenere un nuovo lavoro! Il test è fondamentale per migliorare la vostra fiducia nel software.

unit testing dà il massimo valore quando si hanno un sacco di codice. E 'facile per eseguire il debug di un semplice compito a casa con un paio di classi, senza unit testing. Una volta arrivati ??nel mondo, e si sta lavorando in basi di codice di milioni di linee - Avrai bisogno. È semplicemente non può solo passo debugger attraverso tutto ciò. Semplicemente non si può capire tutto. Hai bisogno di sapere che le classi si stanno seconda lavoro. Hai bisogno di sapere se qualcuno dice "Devo solo fare questa modifica al comportamento ... perché ne ho bisogno", ma hanno dimenticato che ci sono duecento altri usi che dipendono da tale comportamento. Unit testing aiuta a prevenire questo.

Per quanto riguarda la manutenzione rendendo più difficile:!. NO WAY non posso capitalizzare che sufficiente

Se sei l'unica persona che abbia mai lavorato sul progetto, allora sì, si potrebbe pensare che. Ma questo è parlare pazzo! Cercare di ottenere fino a velocità su un progetto linea 30k senza Unittests. Provare ad aggiungere funzionalità che richiedono modifiche significative al codice senza Unittests. C'è sfiducia che non stai rompendo presupposti impliciti effettuate dagli altri ingegneri. Per un manutentore (o nuovo sviluppatore su un progetto esistente) Unittests sono fondamentali. Ho appoggiai Unittests per la documentazione, per il comportamento, per ipotesi, per dirmi quando ho rotto qualcosa (che ho pensato è stato correlato). A volte un API scritta male è scritto male i test e può essere un incubo per il cambiamento, perché i test succhiano tutto il tuo tempo. Alla fine si sta andando a voler refactoring questo codice e correzione, ma gli utenti vi ringrazierà anche per questo -. Vostra API sarà molto più facile da usare a causa di esso

Una nota sulla copertura:

Per me, non si tratta di copertura di test del 100%. una copertura del 100% non trova tutti i bug, si consideri una funzione con due affermazioni if:

// Will return a number less than or equal to 3
int Bar(bool cond1, bool cond2) {
  int b;
  if (cond1) {
    b++;
  } else {
    b+=2;
  }

  if (cond2) {
    b+=2;
  } else {
    b++;
  }
}

Consideriamo ora scrivo un test che i test:

EXPECT_EQ(3, Bar(true, true));
EXPECT_EQ(3, Bar(false, false));

Questa è una copertura del 100%. Questa è anche una funzione che non soddisfa il contratto -. Bar(false, true); fallisce, perché restituisce 4. Quindi, "copertura completa" non è l'obiettivo finale

Onestamente, vorrei saltare i test per BooksLimit(). Esso restituisce una costante, in modo che probabilmente non vale la pena il tempo di scrivere loro (e dovrebbe essere testato durante la scrittura DisplayBooks()). Potrei essere triste quando qualcuno decide di (erroneamente) calcolare tale limite dalla dimensione mensola, ed esso non risponde più le nostre esigenze. Sono già stato scottato da "non vale la pena di prova" prima. L'anno scorso ho scritto un codice che ho detto al mio collega: "Questa classe è per lo più i dati, non ha bisogno di essere testati". Aveva un metodo. Aveva un bug. E 'andato alla produzione. Ci paging nel bel mezzo della notte. Mi sentivo stupido. Così ho scritto i test. E poi ho riflettuto a lungo su quale codice costituisce "non vale la pena di test". Non c'è molto.

Quindi, sì, è possibile saltare alcuni test. copertura di test 100% è grande, ma non magicamente significa che il software è perfetto. Tutto si riduce alla fiducia di fronte al cambiamento.

Se metto class A, class B e class C insieme, e trovo qualcosa che non funziona, voglio passare il tempo di debug tutti e tre? No. Voglio sapere che A e B già incontrato i loro contratti (via Unittests) e il mio nuovo codice in class C è probabilmente rotta. Così ho unittest esso. Come faccio nemmeno si è rotto, se non lo faccio unittest? Cliccando alcuni pulsanti e cercando il nuovo codice? Questo è un bene, ma non sufficiente. Una volta che il programma di scale up, sarà impossibile eseguire nuovamente tutti i test manuali per controllare che tutto funziona bene. Ecco perché le persone che di solito unittest automatizzare la gestione delle rispettive prove di troppo. Dimmi "Pass" o "Fail", non dirmi che "l'uscita è ...".

OK, gonna go scrivere un po 'di test ...

Altri suggerimenti

copertura unit test al 100% è in genere un odore di codice, un segno che qualcuno è venuto su tutto OCD sopra la barra verde nello strumento di copertura, invece di fare qualcosa di più utile.

Da qualche parte circa l'85% è il punto debole, in cui in mancanza di un test più spesso che non indica un problema reale o potenziale, piuttosto che essere semplicemente una conseguenza inevitabile di ogni modifica testuale non commento marcatori all'interno. Non sei la documentazione di eventuali ipotesi utili sul codice, se le vostre ipotesi sono 'il codice è quello che è, e se era in qualche modo diverso sarebbe un'altra cosa'. Questo è un problema risolto da uno strumento di checksum commento-aware, non una prova di unità.

Vorrei che ci fosse qualche strumento che permetterà di specificare la copertura di destinazione. E poi se accidentalmente su di esso, mostrare le cose in giallo / arancio / rosso di spingere verso l'eliminazione di alcuni dei test aggiuntivi spurie.

Se si guarda a un problema isolato, hai perfettamente ragione. Ma i test di unità sono di coprire tutte le intenzioni che hai per un certo pezzo di codice.

In sostanza, i test di unità formulano le vostre intenzioni. Con un numero crescente di intenzioni, il comportamento del codice da testare può sempre essere controllato contro tutte le intenzioni fatte finora. Ogni volta che viene apportata una modifica, si può dimostrare che non v'è alcun effetto collaterale che rompe le intenzioni esistenti. Ritrovata bug sono altro che l'intenzione (implicita) che non è tenuto dal codice, in modo che a formulare la vostra intenzione come nuovo test (che non riesce in un primo momento) e la correzione di esso.

Per il codice di una volta, unit test non sono davvero vale la pena, perché non si prevedono grandi cambiamenti. Tuttavia, per qualsiasi blocco di codice che deve essere mantenuta o che serve da componente per altro codice, garantendo che tutte le intenzioni sono detenuti per ogni nuova versione vale molto (in termini di meno sforzo per cercare manualmente per verificare gli effetti collaterali) .

Il punto di svolta in cui unità di test effettivamente risparmiare tempo e quindi denaro dipende dalla complessità del codice, ma c'è sempre un punto di svolta che si raggiunge in genere dopo solo poche iterazioni di modifiche. Inoltre, ultima ma non meno importante che consente di spedire le correzioni e cambia molto più velocemente senza compromettere la qualità del prodotto.

Non v'è alcuna relazione tra l'exlpicit copertura del codice e il buon software. Si può facilmente immaginare pezzo di codice che ha il 100% (o quasi) la copertura del codice e contiene ancora un sacco di bug. (Che non vuol dire che i test sono male!)

La tua domanda riguardo l'agilità di 'nessun test all' approccio è un bene solo per breve prospettiva (che significa che è più probabile che non va bene se si prevede di costruire il vostro programma per più tempo). So dalla mia esperienza che tali prove semplici sono molto utili quando il progetto diventa sempre più grande e ad un certo punto è necessario apportare modifiche significative. Questo può essere un momment quando ti dici a te stesso 'E' stata una buona decisione per trascorrere alcuni minuti in più per scrivere quel piccolo test che maculato bug che ho appena introdotto! ".

Sono stato un grande fan di copertura del codice di recente, ma ora si è scoperto (luckilly) a qualcosa come 'copertura problemi' approccio. Ciò significa che i test dovrebbero coprire tutti i problemi e bug che sono stati visti non solo 'linee di codice' . Non c'è bisogno di fare un 'razza copertura del codice' .

Capisco parola 'Agile' in termini di test numero come 'numero di test che mi aiuta a costruire un buon software e non perdere tempo a scrivere pezzo inutile di codice' , piuttosto che 'una copertura del 100%' o 'nessun test a tutti'. E 'molto soggettivo ed è basato sulla vostra esperienza, la squadra, la tecnologia e molti altri fattori.

L'effetto collaterale psicologico di 'copertura del codice 100%' è che si potrebbe pensare che il codice non ha bug, che non è vero:)

Sono d'accordo con @soru, copertura di test del 100% non è un obiettivo razionale.

Non credo che qualsiasi strumento o la metrica possono esistere che può dire la quantità "giusta" di copertura. Quando ero a scuola grad, il lavoro la mia Tesi di consigliere era sulla progettazione copertura di test per il codice "mutato". E 'prendere una suite di test, e quindi eseguire un programma automatico per fare errori nel codice sorgente in prova. L'idea era che il codice mutato conteneva errori che potrebbero essere trovati nel mondo reale, e, quindi, una suite di test che ha trovato la più alta percentuale di codice rotto è stato il vincitore.

Mentre la sua tesi è stata accettata, e lui ora è un professore in una scuola di ingegneria importante, che non ha trovato uno:

1) un numero magico di copertura di test che è ottimale 2) tutte le suite che poteva trovare il 100% degli errori.

Nota, l'obiettivo è quello di trovare il 100% degli errori, di non trovare una copertura del 100%.

Sia @ di Soru 85% è giusto o non è un oggetto di discussione. Non ho alcun mezzo per valutare se un numero migliore sarebbe 80% o il 90% o qualsiasi altra cosa. Ma come una valutazione di lavoro, 85% sente su giusto per me.

Ci dispiace per il mio inglese.

100% di copertura del codice è un disturbo fisiologico gestionale per impressionare gli stakeholder artificialmente. Noi testando perché c'è qualche codice complesso là fuori che può portare a difetti. Quindi abbiamo bisogno di fare in modo che il codice complesso dispone di un banco di prova, la sua testati e difetti sono fissate prima della sua diretta.

dovrebbe mirare a prova di qualcosa che è complessa e non proprio tutto. Ora questo complesso ha bisogno di essere espresse in termini di un numero metrico che può essere etere complessità ciclomatica, linee di codice, aggregazioni, ecc accoppiamento o il suo culmine probabilmente di tutte le cose di cui sopra. Se troviamo che più alto metrica dobbiamo fare in modo che, che parte del codice è coperto. Di seguito è riportato il mio articolo che riguarda ciò che è la migliore% per la copertura del codice.

Is copertura del 100% del codice veramente necessario?

Per prima al 100% è difficile da ottenere in particolare su grandi progetti! e anche se si fa quando un blocco di codice è coperto non significa che si sta facendo quello che si suppone che a meno che il test sono affermando ogni possibile ingresso e di uscita (che è quasi impossibile).

Quindi mi sento di non considerare un pezzo di software per essere buono semplicemente perché ha copertura del codice 100%, ma la copertura di codice ancora una buona cosa avere.

Beh, non è molto più facile andare direttamente al terzo passo, e non fanno mai BooksLimit) test di unità (a tutti?

bene avere quel test ci rende abbastanza fiducioso che se qualcuno cambia il codice e il test fallisce si noterà che qualcosa non va con il nuovo codice di conseguenza si evita qualsiasi bug potencial nell'applicazione

Quando il cliente decide di cambiare il limite a 200, buona fortuna trovare bug legato a quello di prova apparentemente banale. Specialmente, quando si dispone di altre 100 variabili nel codice, e sono disponibili altre 5 sviluppatori che lavorano sul codice che si basa su quel piccolo pezzo di informazione.

Il mio punto: se è prezioso per il valore di business (o, se non ti piace il nome, al nucleo molto importante del progetto), test di esso. Solo scartare quando non v'è possibile (o conveniente) modo di testarlo, come interfaccia utente o l'interazione dell'utente, o quando si è sicuri che l'impatto di non scrivere quel test è minimo. Questo vale più vero per i progetti con i requisiti vaghi, o rapidamente cambiando [come ho scoperto dolorosamente].

Per l'altro esempio è presente, il raccomandato è quello di testare i valori limite. Così è possibile limitare i test a soli quattro valori:. 0, un numero magico tra 0 e BooksLimit, BooksLimit, e un po 'più alto numero

E, come altre persone hanno detto, fare test, ma essere al 100% qualcosa di positivo altro può fallire.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow