TDD - was: Re: Calcolo del codice fiscale

E qualunque cosa dica un certo DHH, ignoralo. :slight_smile:

Che dice ?
Forse me lo sono perso.

Per DHH il TDD non serve ?

IMO ha ragione… scrivere i test e l'arte di bilanciare il costo di scriverli contro i costi di bug che non avresti scovato altrimenti. Testare troppo, e stai buttando via tempo che avresti potuto dedicare allo sviluppo, testare troppo poco, e magari hai paura di cambiare il codice, perche non hai la sicurezza che funziona dopo.

Rails e nato con i test, non e che stia dicendo di non scriverli, ma
di usare la testa.

Poi, test driven development, ovvero, sviluppare prima i test… non
so, non mi convince. Troppo spesso non so come deve essere
l’applicazione, quindi devo scrivere qualcosa per vedere come viene
fuori. A quel punto, quando inizia a prendere forma, inizio ad
aggiungere i test. Ci vuole un po’ di disciplina, ma visto i benefici,
vale la pena.

–
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Il giorno 25 gennaio 2013 15:05, David W. [email protected]
ha
scritto:

IMO ha ragione… scrivere i test e l'arte di bilanciare il costo di scriverli contro i costi di bug che non avresti scovato altrimenti. Testare troppo, e stai buttando via tempo che avresti potuto dedicare allo sviluppo, testare troppo poco, e magari hai paura di cambiare il codice, perche non hai la sicurezza che funziona dopo.

Rails e nato con i test, non e che stia dicendo di non scriverli, ma
di usare la testa.

Ah beh … sono d’accordo (in parte)
Troppi test (o troppo pochi) non va :slight_smile:

Comunque l’arte di sapere quanti test scrivere (e quanto basta) arriva
dopo
un po’ di esperienza (anche con TDD)

“Perfetto quello che ottieni quando non puoi pi togliere nulla”

Per arrivarci ci vuole un po’ :slight_smile:

Poi, test driven development, ovvero, sviluppare prima i test… non

so, non mi convince. Troppo spesso non so come deve essere
l’applicazione, quindi devo scrivere qualcosa per vedere come viene
fuori. A quel punto, quando inizia a prendere forma, inizio ad
aggiungere i test. Ci vuole un po’ di disciplina, ma visto i benefici,
vale la pena.

Beh si, pu capitare.
Imho l’importante non aspettare di avere code base grossa (ed
incasinata)
Se no finisci per fare
http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
http://mikadomethod.org/
:slight_smile:

Ma se in certi casi parti con buon OOD - OOP e poi aggiungi test (e TDD)
…
Probabilmente anche Beck direbbe “Why not ?”

S.

Il giorno 25 gennaio 2013 14:28, Sergio B.
[email protected]ha scritto:

Completamente d’accordo.
Quando ho iniziato, testavo QUALUNQUE cosa.
Ma un percorso normale, meglio un test in eccesso che uno in difetto.

Poi, test driven development, ovvero, sviluppare prima i test… non

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
http://mikadomethod.org/
:slight_smile:

Ma se in certi casi parti con buon OOD - OOP e poi aggiungi test (e TDD)
…
Probabilmente anche Beck direbbe "Why not ?

Perfettamente d’accordo con il fanta-Beck.
Per attenzione, perch facendo cos alcune parti non si riescono a
testare.

Ciao,

Matteo

Io ho trovato molto comodo inserire con cucumber un test di alto
livello che intercetta il minimo sindacale perch l’applicazione si
possa dire che “funziona”. Quando vedo che c’ una parte da verificare
con maggiore cura vado di unit test.

Cos copro il 30/40% dell’applicazione ma evito buchi clamorosi quando
faccio un refactoring o aggiungo qualcosa.
I bug invece tento di chiuderli con un test sempre.

ciao lo

2013/1/25 Matteo C. [email protected]: