# TDD - was: Re: Calcolo del codice fiscale **URL:** \ **Category:** IT\ **Created:** [January 25, 2013, 3:05pm UTC](https://www.ruby-forum.com/t/tdd-was-re-calcolo-del-codice-fiscale/225721 "2013-01-25T15:05:52Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [January 25, 2013, 3:05pm UTC](https://www.ruby-forum.com/t/tdd-was-re-calcolo-del-codice-fiscale/225721/1 "2013-01-25T15:05:52Z")
> > E qualunque cosa dica un certo DHH, ignoralo. 🙂 > > Che dice ? > Forse me lo sono perso. > > Per DHH il TDD non serve ? > **[Testing like the TSA](https://signalvnoise.com/posts/3159-testing-like-the-tsa)** > > When developers first discover the wonders of test-driven development, it’s like gaining entrance to a new and better world with less stress and insecurity. It truly is a wonderful experience well worth celebrating. But internalizing the benefits of... 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.welton.it/davidw/) [http://www.dedasys.com/](http://www.dedasys.com/) ---
**Author:** ![dawillis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ebca7d/32.png) [@dawillis](https://www.ruby-forum.com/u/dawillis)\ **Post date:** [January 25, 2013, 3:28pm UTC](https://www.ruby-forum.com/t/tdd-was-re-calcolo-del-codice-fiscale/225721/2 "2013-01-25T15:28:39Z")
Il giorno 25 gennaio 2013 15:05, David W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > **[Working Effectively with Legacy Code (Robert C. Martin Series): Feathers,...](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)** > > Working Effectively with Legacy Code (Robert C. Martin Series) \[Feathers, Michael\] on Amazon.com. \*FREE\* shipping on qualifying offers. Working Effectively with Legacy Code (Robert C. Martin Series) > **[The Mikado Method](https://mikadomethod.info/)** 🙂 Ma se in certi casi parti con buon OOD - OOP e poi aggiungi test (e TDD) … Probabilmente anche Beck direbbe “Why not ?” S. ---
**Author:** ![dawillis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ebca7d/32.png) [@dawillis](https://www.ruby-forum.com/u/dawillis)\ **Post date:** [January 25, 2013, 5:09pm UTC](https://www.ruby-forum.com/t/tdd-was-re-calcolo-del-codice-fiscale/225721/3 "2013-01-25T17:09:10Z")
Il giorno 25 gennaio 2013 14:28, Sergio B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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 > [Working Effectively with Legacy Code (Robert C. Martin Series): Feathers, Michael: 9780131177055: Amazon.com: Books](http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) > [http://mikadomethod.org/](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 ---
**Author:** ![dawillis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ebca7d/32.png) [@dawillis](https://www.ruby-forum.com/u/dawillis)\ **Post date:** [January 25, 2013, 6:57pm UTC](https://www.ruby-forum.com/t/tdd-was-re-calcolo-del-codice-fiscale/225721/4 "2013-01-25T18:57:19Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):