Quanto sono sufficienti le prove?

Question

Recentemente ho trascorso circa il 70% delle volte durante la codifica di un test di integrazione di funzionalità di scrittura. A un certo punto, stavo pensando "Dannazione, tutto questo duro lavoro lo test, so che non ho bug qui, perché lavoro così tanto su questo? Basta sfiorare i test e finirlo già ... "

Cinque minuti dopo un test fallisce. Un'ispezione dettagliata mostra che si tratta di un bug sconosciuto e importante in una libreria di terze parti che stiamo utilizzando.

Quindi ... dove tracciate la vostra linea su cosa testare su cosa assumere per fede? Metti alla prova tutto o il codice in cui prevedi la maggior parte degli errori?

Answer 1

I test Tutto. Lo odio, ma è una parte importante del mio lavoro.

Answer 2

A mio parere, è importante essere pragmatici quando si tratta di test. Dai priorità ai tuoi sforzi di test sulle cose che hanno più probabilità di fallire, e/o sulle cose che è più importante che non falliscono (cioè prendere in considerazione probabilità e conseguenze).

Pensa, invece di seguire ciecamente una metrica come la copertura del codice.

Fermarsi quando si ha familiarità con la suite di test e il proprio codice. Torna indietro e aggiungi altri test quando (se?) Le cose iniziano a fallire.

Answer 3

Se tu o il tuo team state monitorando le metriche, potete vedere quanti bug sono stati trovati per ogni test mentre il ciclo di vita del software progredisce. Se hai definito una soglia accettabile in cui il tempo speso per il test non giustifica il numero di bug trovati, allora QUELLO è il punto in cui devi fermarti.

Probabilmente non troverai mai il 100% dei tuoi bug.

Answer 4

Trascorro molto tempo sui test unitari, ma molto poco sui test di integrazione. Le unit test mi permettono di costruire una feature in modo strutturato. E ora hai qualche buona documentazione e test di regressione che possono essere eseguiti ogni build

I test di integrazione sono un'altra questione. Sono difficili da mantenere e, per definizione, integrano molte funzionalità diverse, spesso con un'infrastruttura con cui è difficile lavorare.

Answer 5

Buona domanda!

In primo luogo - che suona come il vostro numerosi test di integrazione pagato :)

Dalla mia esperienza personale:

• Se il suo un "prati verdi" nuovo progetto, mi piace far rispettare rigorosi test di unità e avere un piano di test di integrazione completo (completo quanto ) progettato.
• Se il suo un pezzo esistente del software che ha scarsa copertura di test, poi ho preferiscono progettare un'integrazione impostato test che mettono alla prova specifico noto funzionalità /. Quindi introduco i test (unità/integrazione) mentre I progredisce ulteriormente con il codice base.

Quanto è sufficiente? Domanda difficile - Non penso che possa mai esserci abbastanza!

Answer 6

"Troppo di tutto è sufficiente."

Non seguo rigorose pratiche TDD. Cerco di scrivere abbastanza test unitari per coprire tutti i percorsi del codice ed esercitare ogni caso limite che ritengo importante. Praticamente cerco di prevedere cosa potrebbe andare storto. Cerco anche di abbinare la quantità di codice di prova che scrivo a quanto fragile o importante penso sia il codice sotto test.

Sono rigoroso in un'area: se viene rilevato un errore, prima scrivo un test che esegue il bug e non riesce, apporta le modifiche al codice e verifica che il test passi.

Answer 7

Come tutto nella vita, è limitato dal tempo e dalle risorse e dalla sua importanza. Idealmente testerai tutto ciò che pensi ragionevolmente potrebbe rompere. Certamente puoi sbagliare nella tua stima, ma il test per verificare che le tue ipotesi siano corrette dipende da quanto sarebbe significativo un bug o dalla necessità di passare alla prossima funzione/release/progetto.

Nota: la mia risposta riguarda principalmente i test di integrazione. TDD è molto diverso. Prima era coperto da SO e lì si interrompe il test quando non si hanno più funzionalità da aggiungere. TDD parla di design, non di scoperta di bug.

Answer 8

Quando non si ha più paura di apportare modifiche medio-importanti al codice, è probabile che si abbiano abbastanza test.

Answer 9

Ho lavorato in QA per 1,5 anni prima di diventare uno sviluppatore.

Non si può mai testare tutto (mi è stato detto che una volta addestrate tutte le permutazioni di una singola casella di testo richiederebbero più tempo dell'universo conosciuto).

Come sviluppatore non è responsabilità dell'utente conoscere o indicare le priorità di ciò che è importante testare e cosa non provare. Il test e la qualità del prodotto finale sono responsabilità, ma solo il cliente può dichiarare in modo significativo le priorità delle funzionalità, a meno che non le abbiano esplicitamente attribuito questa responsabilità. Se non c'è un team di QA e non lo sai, chiedi al project manager di scoprire e stabilire le priorità.

Il test è un esercizio di riduzione del rischio e il cliente/utente saprà cosa è importante e cosa no. Sarà utile utilizzare un test sviluppato per la prima volta da Extreme Programming, in modo da avere una buona base di prova e il test di regressione dopo una modifica.

È importante notare che a causa del codice di selezione naturale può diventare "immune" ai test. Il codice completo dice che quando si risolve un difetto per scrivere un caso di prova e cercare difetti simili, è anche una buona idea scrivere un caso di prova per difetti simili ad esso.

Answer 10

Preferisco testare il più possibile. Uno dei più grandi effetti collaterali (oltre ad aumentare la qualità del codice e aiutare a tenere lontani alcuni bug) è che, a mio parere, le aspettative di test di unità elevate richiedono uno per modificare il modo in cui scrivono il codice per il meglio. Almeno, è così che ha funzionato per me.

mie classi sono più coesa, più facile da leggere, e molto più flessibile perché sono stati progettati per essere funzionali e verificabile.

Detto questo, I requisiti di copertura del test dell'unità di default del 90% (linea e diramazione) utilizzano junit e cobertura (per Java). Quando sento che questi requisiti non possono essere soddisfatti a causa della natura di una classe specifica (o bug in cobertura), faccio delle eccezioni.

I test unitari iniziano con la copertura e funzionano davvero per te quando li hai utilizzati per testare le condizioni al bordo in modo realistico. Per consigli su come implementare questo obiettivo, l'altro risponde a tutti che hanno ragione.

Answer 11

This article fornisce alcune informazioni molto interessanti sull'efficacia del test dell'utente con diversi numeri di utenti. Suggerisce che puoi trovare circa due terzi dei tuoi errori con solo tre utenti che testano l'applicazione e fino all'85% dei tuoi errori con soli cinque utenti.

Il test delle unità è più difficile su cui impostare un valore discreto. Un suggerimento da tenere a mente è che il test unitario può aiutare a organizzare i tuoi pensieri su come sviluppare il codice che stai testando. Una volta che hai scritto i requisiti per un pezzo di codice e hai un modo per controllarlo in modo affidabile, puoi scriverlo più rapidamente e in modo affidabile. Classic Book

Answer 12

Gerald Weinberg "The Psychology of Computer Programming" ha un sacco di buone storie di test. Un particolare mi piace è nel capitolo 4" Programming as a Social Activity " 'Bill', chiede un collega di rivedere il suo codice e trovano diciassette bug in soli tredici dichiarazioni Le recensioni di codice forniscono ulteriori occhi per aiutare a trovare i bug, più gli occhi si usano più possibilità di trovare bug sempre così sottili. Come Linus ha detto: "Dato abbastanza occhi, tutti gli insetti sono superficiali" i test sono fondamentalmente occhi robotici chi guarderà il tuo codice tutte le volte che vuoi a qualsiasi ora del giorno o della notte e ti informerà se tutto è ancora kosher

Quanti test sono sufficienti dipende se stai sviluppando da zero o mantenendo un sistema esistente.

Quando si inizia da zero, non si vuole passare tutto il tempo a scrivere il test e non si riesce a consegnare perché il 10% delle funzionalità che si è in grado di codificare sono testate in modo esauriente. Ci sarà un po 'di prioritizzazione da fare. Un esempio sono i metodi privati. Poiché i metodi privati ​​devono essere utilizzati dal codice che è visibile in qualche modo (pubblico/pacchetto/protetto) i metodi privati ​​possono essere considerati coperti dai test per i metodi più visibili. Qui è dove devi includere alcuni test white-box se ci sono alcuni comportamenti importanti o oscuri o casi limite nel codice privato.

I test dovrebbero aiutarti a verificare 1) i requisiti, 2) rispettare le buone pratiche di progettazione mediante la codifica per la testabilità e 3) sapere quando il codice precedentemente esistente smette di funzionare. Se non è possibile descrivere un test per alcune funzionalità, sarei disposto a scommettere che non si capisce la funzione abbastanza bene da codificarla in modo pulito. L'uso del codice di test unitario ti costringe a fare cose come passare argomenti come cose importanti come connessioni di database o fabbriche di istanze invece di cedere alla tentazione di lasciare che la classe faccia troppo da sola e trasformarsi in un oggetto "Dio". Lascia che il tuo codice sia il tuo canarino significa che sei libero di scrivere più codice. Quando fallisce un test precedente, significa che una delle due cose è che il codice non fa più ciò che era previsto o che i requisiti per la funzionalità sono cambiati e il test deve semplicemente essere aggiornato per adattarsi ai nuovi requisiti.

Quando si lavora con il codice esistente, si dovrebbe essere in grado di mostrare che tutti gli scenari conosciuti sono coperti in modo che quando la prossima richiesta di cambiamento o correzione del bug arriverà, sarai libero di scavare in qualsiasi modulo tu ritenga opportuno senza il preoccupazione fastidiosa, "cosa succede se rompo qualcosa" che porta a passare più tempo a testare anche piccole correzioni, poi è occorso effettivamente cambiare il codice.

Quindi, non possiamo darti un numero di test duro e veloce ma dovresti girare per un livello di copertura che aumenta la tua fiducia nella tua capacità di continuare a fare cambiamenti o aggiungere funzionalità, altrimenti probabilmente hai raggiunto il punto di rendimenti diminuiti.