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.
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
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
Ma se in certi casi parti con buon OOD - OOP e poi aggiungi test (e TDD)
…
Probabilmente anche Beck direbbe “Why not ?”
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.
