Uncovering better ways of developing software
Unit test sono overrated?
Interessante intervento:
http://www.infoq.com/presentations/francl-testing-overrated
riassumendo dice che:
1) fare i test e' difficile e richiede un mucchio di codice che va mantenuto
2) se sono sbagliati i requisiti, non servono a nulla
3) i test manuali (con una persona non sviluppatore) trovano molti piu' errori
4) le code review funzionano meglio e aiutano a migliorare gli sviluppatori.
io qui banalizzo ovviamente per mancanza di spazio.
Personalmente posso dire che forse e' vero, sono overrated. Pensare di avere un progetto bug-free o scritto bene solo perche' ha una test coverage del 100% e' un wishful thinking.
Detto questo, vanno scritti cmq! ;)
Anche sui punti 3 e 4 sono d'accordo, i test non dovrebbero essere un pretesto per non avere una persona di QA e non fare le code review.
http://www.infoq.com/presentations/francl-testing-overrated
riassumendo dice che:
1) fare i test e' difficile e richiede un mucchio di codice che va mantenuto
2) se sono sbagliati i requisiti, non servono a nulla
3) i test manuali (con una persona non sviluppatore) trovano molti piu' errori
4) le code review funzionano meglio e aiutano a migliorare gli sviluppatori.
io qui banalizzo ovviamente per mancanza di spazio.
Personalmente posso dire che forse e' vero, sono overrated. Pensare di avere un progetto bug-free o scritto bene solo perche' ha una test coverage del 100% e' un wishful thinking.
Detto questo, vanno scritti cmq! ;)
Anche sui punti 3 e 4 sono d'accordo, i test non dovrebbero essere un pretesto per non avere una persona di QA e non fare le code review.
Visualizzazioni: 6
Risposte a questa discussione
-
Permalink Risposto da Luca Marrocco su -
personalmente sono d'accordo con gli argomenti presentati. In realta mi pare che non si parlasse soltanto di unit testing e della sua utilita' quanto del confronto tra i vari tipi di testing rispetto allo unit. Personalemnte ritengo che una code base con una buona code coverage (tendente al 100%) porti il software ad avere un aspetto interno migliore di un applicazione senza unit testing. Inoltre per me il test di unita' e' il software cioe' ne fa parte come l'implementazione che viene testata da questo. In questo caso i problemi di manutenzione, correttezza, leggibilita', testabilita' (validazione delle asserzioni del test) sono gli stessi di sviluppare software e richiedono le stesse abilita'
-
Permalink Risposto da uberto su -
mmmh... se la pensi cosi' allora non puoi essere d'accordo con Luke Francl. ;)
Per esperienza posso assicurarti che ci sono tanti progetti con test coverage 100% scritti da cani.
E' vero che uno si potrebbe chiedere se magari senza test le stesse persone non avrebbero fatto anche di peggio...
-
Permalink Risposto da Riccardo Lemmi su -
Secondo me:
1) fare i test e' difficile e richiede un mucchio di codice che va mantenuto
Nella mia esperienza di sviluppo TDD la sensazione è che il codice si scriva da solo, quindi il contrario: sembra tutto troppo facile.
2) se sono sbagliati i requisiti, non servono a nulla
Vale anche se non si scrivono i test, cioè in generale il codice che scrivi è da buttare, ma fare una distinzione tra il codice delle funzionalità e quello dei test pone lo sviluppatore nell'ottica che i secondi sono un male non necessario e non parte del progetto (questo senza considerare l'utilità aggiuntiva dei doctest, molto usati in Python).
3) i test manuali (con una persona non sviluppatore) trovano molti piu' errori
Dubito fortemente, oltre al fatto che anche se non vuoi fare gli unit test in ambiti complessi devi comunque fare i functional test, proprio per evitare il testing manuale.
4) le code review funzionano meglio e aiutano a migliorare gli sviluppatori.
Le code review vanno fatte comunque, anche in ottica di condivisione e refactoring del codice.
La questione è se ha senso coprire tutto il codice? Secondo me no, si devono coprire le storie, ma questo significa porsi in un contesto di sviluppo TDD, che è esattamente il contrario della cascata: sviluppo le funzionalità poi testo il codice.
-
Permalink Risposto da uberto su
-
1 -> anche a me viene naturale ma obiettivamente a molti sviluppatori no. E occorre formarli
2 -> si il punto non ha molto senso se non nel contesto che da questo punto di vista i test non danno nulla in piu'.
3 -> l'ideale e' che il tester (e non lo sviluppatore) scriva e mantenga una suite di test tipo selenium, ci mette di sicuro di meno che farli a mano.
4 -> non avrei saputo dirlo meglio
-
Permalink Risposto da Emanuele DelBono su -
Dico la mia.
> 1) fare i test e' difficile e richiede un mucchio di codice che va mantenuto
Fare test a posteriori è molto difficile e non sempre fattibile, il codice dei test va mantenuto, ma questo non vuol dire che non siano utili. Soprattutto sui bug di regressione.
Io preferisco il TDD che semplifica la scrittura dei test e garantisce migliore codice di produzione.
2) se sono sbagliati i requisiti, non servono a nulla
ok, ma se sono sbagliati i requisiti c'è poco da fare.
3) i test manuali (con una persona non sviluppatore) trovano molti piu' errori
dipende da chi è la persona, da che voglia ha di testare, da cosa ha fatto la sera prima, da come sta il suo gatto ecc....un essere umano è per forza di cosa "influenzato" da ciò che gli sta intorno. Una suite di test è sempre quella e testa sempre le stesse cose.
4) le code review funzionano meglio e aiutano a migliorare gli sviluppatori.
Le code review vanno in parallelo, trovo difficile metterle a confronto.
naturally IMHO.
emanuele
© 2012 Creato da Marco.
