La cosa che ho scoperto su TDD è che ci vuole tempo per impostare i tuoi test ed essendo naturalmente pigro voglio sempre scrivere il minor numero di codice possibile. La prima cosa che mi sembra di fare è testare che il mio costruttore abbia impostato tutte le proprietà, ma è eccessivo?
La mia domanda è: a quale livello di granularità scrivi i tuoi unit test?
..e c'è un caso di test troppo?
Risposte:
Vengo pagato per codice che funziona, non per i test, quindi la mia filosofia è testare il meno possibile per raggiungere un determinato livello di fiducia (sospetto che questo livello di fiducia sia alto rispetto agli standard del settore, ma potrebbe essere solo arroganza) . Se in genere non commetto una sorta di errore (come impostare le variabili sbagliate in un costruttore), non lo test. Tendo a dare un senso agli errori di test, quindi sono molto attento quando ho logica con condizionali complicati. Quando creo codice in un team, modifico la mia strategia per testare attentamente il codice che, collettivamente, tendiamo a sbagliare.
Persone diverse avranno strategie di test diverse basate su questa filosofia, ma mi sembra ragionevole dato lo stato di comprensione immaturo di come i test possono adattarsi al meglio nel ciclo interno della codifica. Tra dieci o vent'anni probabilmente avremo una teoria più universale su quali test scrivere, quali test non scrivere e come distinguere. Nel frattempo, la sperimentazione sembra in ordine.
Scrivi unit test per le cose che ti aspetti di rompere e per i casi limite. Successivamente, i casi di test dovrebbero essere aggiunti man mano che arrivano le segnalazioni di bug, prima di scrivere la correzione del bug. Lo sviluppatore può quindi essere certo che:
Secondo il commento allegato - Immagino che questo approccio alla scrittura di unit test possa causare problemi, se molti bug vengono, nel tempo, scoperti in una data classe. Questo è probabilmente il punto in cui la discrezione è utile, aggiungendo unit test solo per i bug che è probabile che si ripresentino, o dove il loro ripetersi potrebbe causare seri problemi. Ho scoperto che una misura del test di integrazione nei test unitari può essere utile in questi scenari: il test del codice più in alto i codepath possono coprire i codepath più in basso.
Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice. - A. Einstein
Una delle cose più fraintese su TDD è la prima parola in esso. Test. Ecco perché è arrivato BDD. Perché le persone non capivano davvero che la prima D era quella importante, ovvero Driven. Tendiamo tutti a pensare un po 'troppo ai test e un po' troppo alla guida del design. E immagino che questa sia una risposta vaga alla tua domanda, ma dovresti probabilmente considerare come guidare il tuo codice, invece di quello che stai effettivamente testando; questo è qualcosa in cui uno strumento di copertura può aiutarti. Il design è una questione molto più grande e problematica.
A coloro che propongono di testare "tutto": rendersi conto che "testare completamente" un metodo come int square(int x)richiede circa 4 miliardi di casi di test in linguaggi comuni e ambienti tipici.
In realtà, è anche peggio di quello: un metodo void setX(int newX)è inoltre tenuto non alterare i valori di tutti gli altri membri oltre x- stai testando che obj.y, obj.zecc tutti rimangono invariati dopo aver chiamato obj.setX(42);?
È solo pratico testare un sottoinsieme di "tutto". Una volta accettato questo, diventa più appetibile considerare di non testare un comportamento incredibilmente semplice. Ogni programmatore ha una distribuzione di probabilità delle posizioni dei bug; l'approccio intelligente consiste nel concentrare le proprie energie sui test delle regioni in cui si stima che la probabilità di bug sia alta.
La risposta classica è "prova tutto ciò che potrebbe rompersi". Lo interpreto nel senso che testare setter e getter che non fanno nulla tranne set o get è probabilmente troppo test, non c'è bisogno di prendere tempo. A meno che il tuo IDE non li scriva per te, potresti farlo anche tu.
Se il tuo costruttore non imposta le proprietà potrebbe portare a errori in un secondo momento, testare che siano impostate non è eccessivo.
Scrivo test per coprire i presupposti delle classi che scriverò. I test applicano i requisiti. In sostanza, se x non può mai essere 3, ad esempio, mi assicurerò che esista un test che soddisfi tale requisito.
Invariabilmente, se non scrivo un test per coprire una condizione, apparirà più tardi durante i test "umani". Ne scriverò sicuramente uno allora, ma preferisco prenderli presto. Penso che il punto sia che il test è noioso (forse) ma necessario. Scrivo abbastanza test per essere completo, ma non di più.
Parte del problema con saltare semplici test ora è che in futuro il refactoring potrebbe rendere quella semplice proprietà molto complicata con molta logica. Penso che l'idea migliore sia che puoi usare i test per verificare i requisiti per il modulo. Se quando superi X dovresti riavere Y, allora è quello che vuoi testare. Quindi, quando modifichi il codice in un secondo momento, puoi verificare che X ti dia Y e puoi aggiungere un test per A ti dà B, quando quel requisito viene aggiunto in seguito.
Ho scoperto che il tempo speso durante lo sviluppo iniziale dei test di scrittura ripaga nella prima o seconda correzione di bug. La capacità di raccogliere codice che non hai esaminato in 3 mesi ed essere ragionevolmente sicuro che la tua correzione copra tutti i casi e "probabilmente" non rompe nulla è estremamente preziosa. Scoprirai anche che i test unitari aiuteranno a valutare i bug ben oltre la traccia dello stack, ecc. Vedere come funzionano e falliscono i singoli pezzi dell'app fornisce una visione approfondita del motivo per cui funzionano o falliscono nel complesso.
Nella maggior parte dei casi, direi che, se c'è della logica, provala. Ciò include costruttori e proprietà, soprattutto quando più di una cosa viene impostata nella proprietà.
Riguardo a troppi test, è discutibile. Alcuni direbbero che tutto dovrebbe essere testato per la robustezza, altri dicono che per un test efficiente, dovrebbero essere testati solo le cose che potrebbero rompersi (cioè la logica).
Mi spingerei di più verso il secondo campo, solo per esperienza personale, ma se qualcuno decidesse di testare tutto, non direi che era troppo ... forse un po 'eccessivo per me, ma non troppo per loro.
Quindi, No, direi che non esiste una cosa come "troppi" test in senso generale, solo per individui.
Test Driven Development significa che interrompi la codifica quando tutti i tuoi test vengono superati.
Se non hai un test per una proprietà, perché dovresti implementarlo? Se non testate / definite il comportamento previsto in caso di assegnazione "illegale", cosa dovrebbe fare la proprietà?
Pertanto sono assolutamente favorevole a testare ogni comportamento che una classe dovrebbe mostrare. Comprese le proprietà "primitive".
Per rendere più facile questo test, ho creato una semplice NUnit TestFixtureche fornisce punti di estensione per l'impostazione / l'acquisizione del valore e prende elenchi di valori validi e non validi e dispone di un singolo test per verificare se la proprietà funziona correttamente. Il test di una singola proprietà potrebbe essere simile a questo:
[TestFixture]
public class Test_MyObject_SomeProperty : PropertyTest<int>
{
private MyObject obj = null;
public override void SetUp() { obj = new MyObject(); }
public override void TearDown() { obj = null; }
public override int Get() { return obj.SomeProperty; }
public override Set(int value) { obj.SomeProperty = value; }
public override IEnumerable<int> SomeValidValues() { return new List() { 1,3,5,7 }; }
public override IEnumerable<int> SomeInvalidValues() { return new List() { 2,4,6 }; }
}
Utilizzando lambda e attributi questo potrebbe anche essere scritto in modo più compatto. Ho capito che MBUnit ha anche un supporto nativo per cose del genere. Il punto però è che il codice precedente cattura l'intento della proprietà.
PS: Probabilmente il PropertyTest dovrebbe anche avere un modo per verificare che le altre proprietà dell'oggetto non siano cambiate. Hmm .. torniamo al tavolo da disegno.
Faccio unit test per raggiungere la massima copertura possibile. Se non riesco a raggiungere un codice, eseguo il refactoring fino a quando la copertura non è il più completa possibile
Dopo aver finito il test di scrittura accecante, di solito scrivo un caso di test riproducendo ogni bug
Sono abituato a separare tra test del codice e test di integrazione. Durante i test di integrazione (che sono anche test di unità ma su gruppi di componenti, quindi non esattamente a cosa servono i test di unità) testerò per implementare correttamente i requisiti.
Quindi più guido la mia programmazione scrivendo test, meno mi preoccupo del livello di granualità dei test. Guardando indietro sembra che stia facendo la cosa più semplice possibile per raggiungere il mio obiettivo di convalidare il comportamento . Ciò significa che sto generando uno strato di fiducia che il mio codice stia facendo ciò che chiedo di fare, tuttavia ciò non è considerato come una garanzia assoluta che il mio codice sia privo di bug. Ritengo che il giusto equilibrio sia testare il comportamento standard e forse uno o due casi limite, quindi passare alla parte successiva del mio progetto.
Accetto che questo non coprirà tutti i bug e utilizzo altri metodi di test tradizionali per catturarli.
In generale, inizio in piccolo, con input e output che so devono funzionare. Quindi, mentre correggo i bug, aggiungo più test per assicurarmi che le cose che ho risolto siano testate. È organico e funziona bene per me.
Puoi testare troppo? Probabilmente, ma probabilmente è meglio sbagliare sul lato della cautela in generale, anche se dipenderà da quanto sia critica la tua applicazione.
Penso che tu debba testare tutto nel tuo "nucleo" della tua logica di business. Getter e anche Setter perché potrebbero accettare un valore negativo o un valore nullo che potresti non voler accettare. Se hai tempo (dipende sempre dal tuo capo) è bene testare altre logiche di business e tutti i controller che chiamano questi oggetti (si passa dallo unit test al test di integrazione lentamente).
Non collaudo semplici metodi setter / getter che non hanno effetti collaterali. Ma eseguo un test unitario con ogni altro metodo pubblico. Cerco di creare test per tutte le condizioni al contorno nei miei algoritmi e controllo la copertura dei miei test unitari.
È un sacco di lavoro ma penso che ne valga la pena. Preferirei scrivere codice (anche testare il codice) piuttosto che passare da un codice all'altro in un debugger. Trovo che il ciclo code-build-deploy-debug richieda molto tempo e più esaurienti sono gli unit test che ho integrato nella mia build, meno tempo trascorro nel ciclo di code-build-deploy-debug.
Non hai detto perché stai codificando anche l'architettura. Ma per Java io uso Maven 2 , JUnit , DBUnit , Cobertura , e EasyMock .
Più leggo su di esso più penso che alcuni test unitari siano proprio come alcuni schemi: Un odore di lingue insufficienti.
Quando devi verificare se il tuo banale getter restituisce effettivamente il valore corretto, è perché potresti mescolare il nome del getter e il nome della variabile membro. Inserisci 'attr_reader: name' di ruby, e questo non può più accadere. Semplicemente non possibile in Java.
Se il tuo getter non diventa mai banale, puoi comunque aggiungere un test per questo.
Testa il codice sorgente che ti preoccupa.
Non è utile testare porzioni di codice in cui si è molto fiduciosi, purché non si commettano errori.
Prova le correzioni dei bug, in modo che sia la prima e l'ultima volta che risolvi un bug.
Esegui il test per acquisire confidenza con parti di codice oscure, in modo da creare conoscenza.
Test prima del refactoring pesante e medio, in modo da non interrompere le funzionalità esistenti.
Questa risposta è più utile per capire quanti unit test utilizzare per un dato metodo che sai di voler eseguire unit test a causa della sua criticità / importanza. Utilizzando la tecnica Basis Path Testing di McCabe, è possibile eseguire le seguenti operazioni per ottenere quantitativamente una maggiore sicurezza della copertura del codice rispetto alla semplice "copertura delle istruzioni" o "copertura delle filiali":