Inizio TDD - Sfide?Soluzioni?Consigli?[Chiuso]

StackOverflow https://stackoverflow.com/questions/24965

Domanda

OK, so che ci sono già state domande a riguardo iniziare con TDD..Tuttavia, immagino di sapere che il consenso generale è quello fallo e basta , Tuttavia, mi sembra di avere i seguenti problemi a concentrarmi sul gioco:

  • Quando si lavora con le raccolte, verrà comunque eseguito il test per l'evidente aggiunta/rimozione/inserimento riuscito, anche se basato su generici ecc. dove in un certo senso "sappiamo" che funzionerà?
  • Alcuni test sembrano richiedere un'eternità per essere implementati.Ad esempio, quando si lavora con l'output di stringhe, esiste un modo "migliore" per eseguire questo genere di cose?(per esempio.testare il modello a oggetti prima dell'analisi, suddividere l'analisi in piccole operazioni e testare lì) Nella mia mente dovresti sempre testare il "risultato finale", ma ciò può variare notevolmente ed essere noioso da configurare.
  • Non ho un framework di test da utilizzare (il lavoro non ne pagherà uno), quindi posso "esercitarmi" di più.Ce ne sono di buoni gratuiti per uso commerciale?(al momento sto usando il buon vecchio Debug.Assert :)
  • Probabilmente il più grande..A volte non so cosa aspettarmi NON accadere..Voglio dire, ottieni il via libera ma ho sempre paura di perdere un test..Scavi più a fondo per provare a infrangere il codice, oppure lo lasci così e aspetti che tutto cada più tardi (il che costerà di più).

Quindi in pratica quello che sto cercando qui non è un " fallo e basta " ma più " L'ho fatto, ho avuto problemi con questo, li ho risolti con questo "..IL personale esperienza :)

È stato utile?

Soluzione

Innanzitutto, è giusto e normale sentirsi frustrati quando si inizia a provare a utilizzare TDD nel proprio stile di codifica.Basta non scoraggiarti e smettere, dovrai dargli un po' di tempo.È un importante cambiamento di paradigma nel modo in cui pensiamo di risolvere un problema nel codice.Mi piace pensarlo come quando siamo passati dalla programmazione procedurale a quella orientata agli oggetti.

In secondo luogo, ritengo che lo sviluppo basato sui test sia innanzitutto un'attività di progettazione utilizzata per arricchire la progettazione di un componente creando un test che descriva innanzitutto l'API che verrà esposta e il modo in cui ne utilizzerai le funzionalità.Il test aiuterà a modellare e modellare il sistema sotto test finché non sarai in grado di incapsulare funzionalità sufficienti per soddisfare qualsiasi attività su cui stai lavorando.

Tenendo presente il paragrafo precedente, esaminiamo le tue domande:

  1. Se sto utilizzando una raccolta nel mio sistema sotto test, imposterò un'aspettativa per assicurarmi che il codice sia stato chiamato per inserire l'elemento e quindi affermare il conteggio della raccolta.Non provo necessariamente il metodo Aggiungi nel mio elenco interno.Mi assicuro solo che sia stato chiamato quando viene chiamato il metodo che aggiunge l'elemento.Lo faccio aggiungendo un framework beffardo al mix, con il mio framework di test.
  2. Testare le stringhe come output può essere noioso.Non è possibile tenere conto di ogni risultato.Puoi testare solo ciò che ti aspetti in base alla funzionalità del sistema in prova.Dovresti sempre suddividere i tuoi test fino all'elemento più piccolo da testare.Ciò significa che avrai molti test, ma test piccoli e veloci e che testeranno solo ciò che dovrebbero, nient'altro.
  3. Esistono molti framework di test open source tra cui scegliere.Non discuterò su quale sia il migliore.Trovane uno che ti piace e inizia a usarlo.
  4. Tutto quello che puoi fare è impostare i tuoi test per tenere conto di ciò che vuoi che accada.Se si presenta uno scenario che introduce un bug nella tua funzionalità, almeno fai un test sulla funzionalità per aggiungere quello scenario al test e quindi modificare la funzionalità finché il test non viene superato.Un modo per scoprire dove potremmo aver perso un test è utilizzare copertura del codice.

Ti ho presentato il termine beffardo nella risposta alla domanda uno.Quando introduci il mocking nel tuo arsenale per TDD, diventa notevolmente più semplice astrarre le parti che non fanno parte del sistema sotto test.Ecco alcune risorse sui framework beffardi disponibili:

Un modo per aiutare nell'uso del TDD, oltre a leggere il processo, è guardare le persone mentre lo fanno.Consiglio di guardare le trasmissioni sullo schermo di JP Boodhoo su DNRTV.Dai un'occhiata a questi:

OK, questi ti aiuteranno a vedere come vengono utilizzati i termini che ho introdotto.Introdurrà anche un altro strumento chiamato Riaffilatore e come può facilitare il processo TDD.Non potrei raccomandare abbastanza questo strumento durante l'esecuzione di TDD.Sembra che tu stia imparando il processo e stai solo scoprendo alcuni dei problemi che sono già stati risolti utilizzando altri strumenti.

Penso che farei un'ingiustizia alla comunità se non aggiornassi questa pagina aggiungendo la nuova serie di Kent Beck su Sviluppo guidato dai test su programmatore pragmatico.

Altri suggerimenti

Dalla mia esperienza:

  1. Testa solo il tuo codice, non quello del framework sottostante.Quindi, se stai utilizzando un elenco generico, non è necessario testare Aggiungi, Rimuovi ecc.

  2. Non ce n'è 2.Guarda là!Scimmie!!!

  3. NUnità è la strada da percorrere.

  4. Sicuramente non puoi testare ogni risultato.Provo ciò che mi aspetto che accada, quindi provo alcuni casi limite in cui mi aspetto di ottenere eccezioni o risposte non valide.Se si verifica un bug a causa di qualcosa che hai dimenticato di testare, la prima cosa che dovresti fare (prima di provare a correggere il bug) è scrivere un test per dimostrare che il bug esiste.

La mia opinione su questo è la seguente:

  • +1 per non testare il codice del framework, ma potrebbe comunque essere necessario testare le classi derivate dalle classi del framework.
  • Se alcune classi/metodi sono difficili da testare, potrebbe essere una forte indicazione che qualcosa non va nella progettazione.Cerco di seguire il principio "1 lezione - 1 responsabilità, 1 metodo - 1 azione".In questo modo sarai in grado di testare metodi complessi molto più facilmente facendolo in porzioni più piccole.
  • +1 per xUnità.Per Java potresti anche prendere in considerazione ProvaNG.
  • Il TDD non è un singolo evento, è un processo.Quindi non cercare di immaginare tutto dall'inizio, ma assicurati che ogni bug trovato nel codice venga effettivamente coperto da test una volta scoperto.

Penso che la cosa più importante (e in realtà uno dei grandi risultati di, in modo un po' ricorsivo) TDD sia la gestione efficace delle dipendenze.È necessario assicurarsi che i moduli vengano testati isolatamente senza che sia necessaria una configurazione elaborata.Ad esempio, se stai testando un componente che alla fine invia un'e-mail, rendi il mittente dell'e-mail una dipendenza in modo da poterlo simulare nei tuoi test.Questo porta ad un secondo punto: i mock sono tuoi amici.Familiarizzare con i framework beffardi e lo stile dei test che promuovono (comportamentali, in contrapposizione ai classici test statali) e le scelte di progettazione che incoraggiano (The "Racconta, non chiedere" principio).

Ho riscontrato che i principi illustrati nel Tre schede per ricordare facilmente l'essenza del TDD è una buona guida.

Comunque per rispondere alle tue domande

  1. Non devi testare qualcosa che "sai" funzionerà, a meno che tu non lo abbia scritto.Non hai scritto i generici, lo ha fatto Microsoft ;)
  2. Se hai bisogno di fare così tanto per il tuo test, forse anche il tuo oggetto/metodo sta facendo troppo.
  3. Scaricamento TestDriven.NET per avviare immediatamente lo unit test sul tuo Visual Studio, (tranne se si tratta di un'edizione Express)
  4. Basta testare il cosa giusta che accadrà.Tu no Bisogno per testare tutto ciò che può andare storto:devi aspettare che i tuoi test falliscano.

Sul serio, fallo e basta, amico.:)

Non sono assolutamente un esperto di TDD, ma ecco il mio punto di vista:

  • Se è completamente banale (getter/setter ecc.) non testarlo, a meno che tu non abbia fiducia nel codice per qualche motivo.
  • Se è un metodo abbastanza semplice, ma non banale, provalo.Probabilmente il test è comunque facile da scrivere.
  • Quando si tratta di cosa aspettarsi che non accada, direi che se un determinato potenziale problema è responsabilità della classe che stai testando, devi verificare che lo gestisca correttamente.Se non è responsabilità della classe corrente, non testarla.

I framework di test xUnit sono spesso gratuiti, quindi se sei un tipo .Net, dai un'occhiata a NUnit e se Java fa per te, dai un'occhiata a JUnit.

Il consiglio di cui sopra è buono e se desideri un elenco di framework gratuiti non devi cercare oltre il file Elenco dei framework xUnit suWikipedia.Spero che questo ti aiuti :)

Secondo me (il tuo chilometraggio può variare):

1- Se non l'hai scritto tu non testarlo.Se l'hai scritto e non hai un test per questo, non esiste.

3- Come dicono tutti, xUnit è gratuito e fantastico.

2 e 4- Decidere esattamente cosa testare è una di quelle cose su cui puoi discutere con te stesso per sempre.Cerco di tracciare questa linea utilizzando i principi del design by contract.Dai un'occhiata a "Costruzione di software orientato agli oggetti" o "Il programmatore pragmatico" per i dettagli.

Mantieni i test brevi, "atomici".Testare l'ipotesi più piccola in ciascun test.Rendi ogni TestMethod indipendente, per i test di integrazione creo anche un nuovo database per ogni metodo.Se è necessario creare alcuni dati per ciascun test, utilizzare un metodo "Init".Usa i mock per isolare la classe che stai testando dalle sue dipendenze.

Penso sempre "qual è la quantità minima di codice che devo scrivere per dimostrare che funziona in tutti i casi?"

Nell'ultimo anno mi sono convinto sempre più dei vantaggi del TDD.Le cose che ho imparato lungo il percorso:1) l'iniezione di dipendenza è tua amica.Non sto parlando di inversione di contenitori di controllo e framework per assemblare architetture di plug-in, ma semplicemente di passare le dipendenze al costruttore dell'oggetto sotto test.Ciò ripaga enormi dividendi nella testabilità del tuo codice.2) Sono partito con la passione/fanatismo del convertito e ho preso un framework beffardo e ho iniziato a usare mock per tutto ciò che potevo.Ciò ha portato a test fragili che hanno richiesto molte dolorose impostazioni e che si sarebbero interrotti non appena avessi iniziato il refactoring.Utilizza il tipo corretto di test double.Falsi in cui devi solo onorare un'interfaccia, stub per fornire dati all'oggetto sotto test, deridere solo dove ti interessa l'interazione.3) Il test dovrebbe essere piccolo.Punta a un'asserzione o interazione da testare in ciascun test.Provo a farlo e per lo più ci sono.Si tratta della robustezza del codice di test e anche della quantità di complessità di un test quando è necessario rivisitarlo in un secondo momento.

Il problema più grande che ho avuto con TDD è stato lavorare con una specifica di un ente di standardizzazione e un'implementazione di terze parti di quello standard che era lo standard de facto.Ho codificato molti test unitari davvero interessanti rispettando alla lettera le specifiche solo per scoprire che l'implementazione dall'altra parte della barricata vedeva lo standard più come un documento consultivo.Hanno giocato abbastanza liberamente con questo.L'unico modo per risolvere questo problema era testare l'implementazione e gli unit test e rifattorizzare i test e il codice secondo necessità.Il vero problema era la convinzione da parte mia che finché avevo codice e test unitari tutto andava bene.Non così.È necessario creare output effettivi ed eseguire test funzionali contemporaneamente ai test unitari.Piccoli vantaggi durante tutto il processo, nelle mani degli utenti o delle parti interessate.

In aggiunta a questo, ho pensato di dire che ho messo a post sul blog sui miei pensieri su come iniziare con i test (seguendo questa discussione e la mia ricerca), poiché potrebbe essere utile alle persone che visualizzano questo thread.

"TDD: iniziare con lo sviluppo basato sui test" - Finora ho ricevuto ottimi riscontri e apprezzerei molto qualsiasi cosa abbiate da offrirmi.

Spero che aiuti!:)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top