TDD, quali sono le tue tecniche per trovare buoni test?

Question

Sto scrivendo una semplice app Web usando Linq to Sql come mio datalayer poiché mi piace molto Linq2Sql. Ultimamente ho letto un po 'di DDD e TDD e volevo provarlo.

Innanzitutto mi sembra che Linq2Sql e DDD non vadano troppo d'accordo. L'altro mio problema è trovare i test, in realtà trovo molto difficile definire buoni test, quindi volevo chiederti: quali sono le tue migliori tecniche per scoprire buoni casi di test.

Answer 1

La scoperta di Test Case è più un'arte che una scienza. Tuttavia le linee guida semplici includono:

• Codice che sai essere fragile / debole / che probabilmente si romperà
• Segui lo scenario dell'utente (cosa farà il tuo utente) e vedi come toccherà il tuo codice (spesso questo significa Debug, altre volte la profilazione, e altre volte significa semplicemente pensare allo scenario) - qualunque cosa punti nel tuo il codice viene toccato dall'utente, quelli hanno la massima priorità su cui scrivere i test.
• Durante il tuo sviluppo i test che hai eseguito che hanno provocato bug che hai trovato - scrivi test per evitare che il codice regredisca di nuovo con lo stesso comportamento.

Esistono diversi libri su come scrivere casi di test là fuori, ma a meno che tu non stia lavorando in una grande organizzazione che richiede casi di test documentati, la cosa migliore da fare è pensare a tutte le parti del tuo codice che non ti piacciono (che non sono " pure ") e assicurati di poter testare accuratamente quei moduli.

Answer 2

Bene, seguendo l'interpretazione standard di TDD è che i test guidano il tuo sviluppo. Quindi, in sostanza, inizi con il test. Non andrà a buon fine e scriverai il codice fino al superamento del test. Quindi è un po 'guidato dalle tue esigenze, comunque raccogli quelle. Decidi tu cosa deve fare la tua app / funzionalità, scrivi il test, quindi codifica fino a quando non passa. Naturalmente, ci sono molte altre tecniche, ma questa è solo una breve affermazione di ciò che si pensa in genere nel mondo TDD.

Answer 3

Pensate . Leggi il codice Mettiti in discussione: ad es. questo puntatore non può mai essere NULL qui? Cosa succede se questo metodo viene chiamato prima dell'inizializzazione?

Non fare ipotesi come " questo file sarà sempre lì " ;. Test.

Pensa ai casi limite, ai confini, ai valori negativi, agli overflow ...

I bug sono spesso raggruppati per cluster. Guardati intorno quando ne trovi uno. Cerca anche lo stesso tipo di bug in altre posizioni.

Answer 4

Pensa all'obiettivo reale del test: trovare i bug.

Sii creativo nell'immaginare cosa potrebbe far fallire il tuo programma.

I tuoi test devono trovare bug, non confermare che il tuo programma sia OK.

Answer 5

Scrivo regolarmente test per API di terze parti. In questo modo, quando l'API si aggiorna, so se ho intenzione di rompere o meno.

Answer 6

Penso che questa sia una tecnica utile:

Utilizzo di contratti e query booleane per migliorare la qualità della generazione automatica di test

---

Riferimento: Lisa (Ling) Liu, Bertrand Meyer e Bernd Schoeller, Utilizzo di contratti e query booleane per migliorare il qualità della generazione automatica dei test , nei procedimenti di TAP: test E prove , ETH Zurigo, 5-6 febbraio 2007, eds. Yuri Gurevich e Bertrand Meyer, Appunti di lezione di Informatica, Springer- Verlag, 2007.