copertura di test è una misura adeguata della qualità del codice?

Question

Se ho un codice che ha una copertura di test 80% (tutti i test passano), è giusto dire che è di qualità superiore rispetto al codice senza copertura di test?

O è giusto dire che è più gestibile?

Answer 1

In senso stretto, non è giusto fare eventuali reclami fino a stabilire la qualità della suite di test. Passando il 100% dei test non è significativa se la maggior parte dei test sono banali o ripetitivi con l'altro.

La domanda è:? Nella storia del progetto, ha fatto uno qualsiasi di questi test Scoprire bug L'obiettivo di un test è quello di trovare bug. E se così non fosse, non sono riusciti come test. Invece di migliorare la qualità del codice, potrebbero essere ti dà solo un falso senso di sicurezza.

Per migliorare voi disegni di prova, è possibile utilizzare (1) whitebox tecniche, (2) le tecniche di Blackbox, e (3) il test di mutazione.

(1) Qui ci sono alcuni buoni whitebox tecniche da applicare ai vostri disegni di prova. Un test whitebox è costruito con il codice sorgente specifico in mente. Un aspetto importante del test strutturale è la copertura del codice:

• è ogni funzione chiamata? [Copertura funzionale]
• è ogni istruzione eseguita? [Dichiarazione coverage-- Sia copertura funzionale e la copertura delle istruzioni sono molto semplici, ma meglio di niente]
• Per ogni decisione (come if o while), avete una prova che le forze che sia vero, e l'altro che le forze di essere falsa? [Copertura decisione]
• Per ogni condizione che è una congiunzione (usi &&) o disgiunzione (usi ||), non ogni sottoespressione ha un test in cui è vero / falso? [Copertura delle condizioni]
Copertura
• loop:? Avete un test che forze 0 iterazioni, 1 iterazione, 2 iterazioni
• è ogni break da un ciclo coperto?

(2) tecniche Blackbox vengono utilizzati quando i requisiti sono disponibili, ma il codice stesso non è. Questi possono portare a prove di alta qualità:

• fare i test blackbox coprono molteplici obiettivi di test? Ti consigliamo i test per essere "grasso":. Non solo test di funzione X, ma anche testare Y e Z. L'interazione di caratteristiche diverse è un ottimo modo per trovare i bug
• L'unico caso che non vuoi le prove "grasso" è quando si sta testando una condizione di errore. Ad esempio, il test per l'input utente non valido. Se si è tentato di raggiungere obiettivi multipli di test di ingresso non validi (ad esempio, un codice postale valido e un indirizzo non valido) è probabile che un caso è mascherare l'altro.
• Considerare i tipi di input e formare una "classe di equivalenza" per i tipi di ingressi. Ad esempio, se i test di codice per vedere se un triangolo è equilatero, il test che utilizza un triangolo con i lati (1, 1, 1) probabilmente trovare gli stessi tipi di errori che i dati di test (2, 2, 2) e (3, 3, 3) troverà. E 'meglio spendere il vostro tempo a pensare di altre classi di ingresso. Ad esempio, se il programma gestisce le tasse, si vorrà un test per ogni fascia d'imposta. [Questo è chiamato partizionamento di equivalenza.]
• Casi particolari sono spesso associate a difetti. I Suoi dati dei test dovrebbero anche avere valori al contorno, come quelli su, sopra o sotto i bordi di un compito di equivalenza. Per esempio, nel test di un algoritmo di ordinamento, ti consigliamo di provare con una matrice vuota, una sola serie di elementi, un array con due elementi, e poi un Very Large Array. Si dovrebbe prendere in considerazione casi limite, non solo per l'ingresso, ma per l'uscita pure. [Questo è l'analisi delle chiamate ai limiti.]
• Un'altra tecnica è "indovinare errore." Hai la sensazione se si cerca una combinazione speciale che si può ottenere il vostro programma di rompere? Poi basta provare! Ricorda: Il tuo obiettivo è quello di trovare gli insetti, non per confermare che il programma è valido . Alcune persone hanno il talento per errore di indovinare.

(3) Infine, supponiamo si dispone già di un sacco di bei test per whitebox copertura, e le tecniche di Blackbox applicata. Che altro si può fare? E 'tempo di Prova i test . Una tecnica è possibile utilizzare è Mutazione test.

In test di mutazione, si effettua una modifica (una copia del) il vostro programma, nella speranza di creatinag un bug. Una mutazione potrebbe essere:

Cambia un riferimento di una variabile ad un'altra variabile; Inserire i abs () la funzione; Cambio meno-che a maggiore di; Eliminare una dichiarazione; Sostituire una variabile con una costante; Eliminare un override dei metodi; Cancellare un riferimento a un metodo eccellente; Modifica ordine degli argomenti

Create diverse decine di mutanti, in vari luoghi nel programma [il programma sarà ancora bisogno di compilare al fine di testare]. Se i test non trovano questi bug, allora è ora necessario scrivere un test che può trovare il bug nella versione mutata del vostro programma. Una volta che un test trova il bug, è stato ucciso il mutante e può provare un altro.

---

Addendum : Ho dimenticato di dire questo effetto: Bugs tendono a raggrupparsi . Ciò significa che i più bug si trovano in un unico modulo, maggiore è la probabilità che troverete più bug. Quindi, se si dispone di un test che non riesce (vale a dire, la prova è riuscita, dal momento che l'obiettivo è quello di trovare gli insetti), non solo si dovrebbe risolvere il bug, ma si dovrebbe anche scrivere altri test per il modulo, utilizzando il tecniche di cui sopra.

Fino a quando si sta trovando bug ad un tasso costante, gli sforzi devono continuare test. Solo quando c'è un calo del tasso di nuovi bug trovato si dovrebbe avere la fiducia che hai fatto attività di test buoni per quella fase dello sviluppo.

Answer 2

Per una definizione è più gestibile, come ogni cambiamento di rottura è più probabilità di essere catturati dai test.

Tuttavia, il fatto che il codice passa i test di unità non significa che sia intrinsecamente di qualità superiore. Il codice potrebbe essere ancora mal formattato con commenti irrilevanti e strutture dati inadeguati, ma può ancora superare le prove.

Lo so quale codice preferisco mantenere ed estendere.

Answer 3

Codice con assolutamente nessun test può essere estremamente alta qualità, leggibile, bella ed efficiente (o spazzatura totale), così no, non è giusto dire che il codice con la copertura di test 80% è di qualità superiore rispetto al codice senza copertura di test .

Potrebbe essere giusto dire che il codice 80% coperto con bene test probabilmente di qualità accettabile, e probabilmente relativamente gestibile. Ma garantisce poco, davvero.

Answer 4

I chiamerei più-refactorable. Refactoring diventa estremamente facile, se il codice è coperto con un sacco di test.

Sarebbe giusto chiamarlo più gestibile.

Answer 5

Sono d'accordo circa la parte mantenibile. Michael Feathers recentemente pubblicato un video di un ottimo intervento della sua chiamata " La profonda sinergia tra verificabilità e buon design ", in cui si discute questo tema. Nel discorso, dice che il rapporto è un modo, cioè, il codice che è ben progettato è testabile, ma codice verificabile non è necessariamente ben progettato.

vale la pena di notare che il video streaming non è grande nel video, quindi potrebbe essere vale la pena scaricare se si vuole guardare in pieno.

Answer 6

Ho chiesto io stesso questa domanda per qualche tempo in relazione alla "condizione di copertura". Così come su questa pagina da atollic.com "Perché l'analisi di copertura del codice? "

Più tecnicamente, il codice di analisi della copertura ritrova aree nel programma non contemplata dai vostri casi di test, che vi permetterà di creare test aggiuntivi che coprono le parti altrimenti non testate del vostro programma. E 'quindi importante capire che copertura di codice che aiuta capire la qualità delle vostre procedure di prova, non la qualità del codice stesso .

Questo sembra essere piuttosto rilevante qui. Se si dispone di un caso di test set che riesce a raggiungere un certo livello di (codice o altro) la copertura, allora siete molto probabile invocando il codice in prova con una serie piuttosto completa dei valori di ingresso! Questo non vi dirà molto circa il codice in prova (a meno che il codice fa saltare in aria o genera errori rilevabili) ma ti dà fiducia nel vostro caso di test set .

In un Cubo di Necker cambiamento di vista, il codice di prova è ora in fase di test dal codice in prova!

Answer 7

Ci sono molti modi per garantire che un programma fa ciò che si intende, e per garantire che le modifiche porteranno effetti non intenzionali.

Test è uno. Evitare la mutazione dei dati è un altro. Quindi è un sistema di tipo. O verifica formale.

Così, mentre sono d'accordo che il test è generalmente una buona cosa, una determinata percentuale di test non potrebbe significare molto. Avrei preferito fare affidamento su qualcosa di scritto in Haskell con nessun test che su una libreria PHP ben collaudato