Forum: Italian Ruby user group TDD - was: Re: Calcolo del codice fiscale

>> E qualunque cosa dica un certo DHH, ignoralo. :-)
>>
>
> Che dice ?
> Forse me lo sono perso.
>
> Per DHH il TDD non serve ?

http://37signals.com/svn/posts/3159-testing-like-the-tsa

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 Welton <davidnwelton@gmail.com> 
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 :)

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' :-)

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-M...
http://mikadomethod.org/
:-)

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 Berisso
<sergio.berisso@gmail.com>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-M...
> http://mikadomethod.org/
> :-)
>
> 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 Collina <matteo.collina@gmail.com>: