Mi togliereste un dubbio sui test?

[RaouL_BennetH]

Ecco

Ho questo dubbio e spero che mi aiutiate ad eliminarlo.

Ma se i test vengono scritti dai programmatori, per fare in modo che il codice che scrivono successivamente, passi questi test.....

1) Se il test stesso è `buggato` o non corretto nel pensiero, che si fa?

2) Se devo scrivere codice per un test che ho pensato, in teoria non sono già a conoscenza del codice corretto per farlo passare e quindi potrei risparmiarmi il test?

Non mangiatemi vivo, sono solo dubbi che ho su un nuovo mondo che sto esplorando, non c'è nessuna vena polemica (per chi vorrebbe per forza vederne una )


Grazie.

RaouL.

[thebol]

Il test non rende il codice corretto. Aiuta a renderlo corretto. E facendo un passo alla volta è meno probabile l'introduzione di errori. In più ai un doppio controllo(capita spesso di scrivere il test sbagliato e il codice giusto ).

Si potresti risparmiarti il test ma:
-i test aiutano a scrivere il codice in maniera semplice e pulita, perchè fanno aggiungere un comportamento(verificato dal test) alla volta.

-i test aiutano quando si va a modificare un pezzo di codice(refactoring o altro), perchè verificano il mantenimento della funzionalita verificata da quel test. Se si è introdotto un bug, c'è buona probabilità(non la certezza) che qualche test fallisca, e ciò rende piu facile la manutenzione.

Sono inoltre molto comodi quando si affronta qualcosa di nuovo, perchè si è obbligati ad andare passo passo, e si commettono (in media) meno errori. Quando invece si lavora su costrutti e funzioni che si conoscono molto bene, alcuni tendono a scrivere test meno pesantemente, avendo più sicurezza in quel che si fa.


per maggiori delucidazioni sui pro e i contro, c'è il libro TDD: Test Driven Development di Kent Beck ( )

[jappilas]

Originariamente inviato da RaouL_BennetH

Ecco

Ho questo dubbio e spero che mi aiutiate ad eliminarlo.

Ma se i test vengono scritti dai programmatori, per fare in modo che il codice che scrivono successivamente, passi questi test.....

1) Se il test stesso è `buggato` o non corretto nel pensiero, che si fa?

lo si verifica ed eventualmente lo si riscrive
un test non è qualcosa di intrinsecamente perfetto, nè di scolpito nella pietra una volta scritto ... è (o almeno dovrebbe puntare a costituire) l' espressione delle specifiche di funzionamento del codice vero e proprio, in forma "programmatica" ( cioè con codice che istanzia degli oggetti e/o ne chiama i metodi per poi verificare i risultati prodotti e lo stato risultante

tali specifiche possono variare da una versione all' altra - questo, è implicito, richiederà la revisione e la riscrittura dei test coinvolti, il che fa intuire l' importanza di una batteria di test scritta e organizzata in modo ordinato e "scalabile" (in questo senso si dovrebbe avere una situazione tanto migliore quanto più i singoli metodi di test sono "atomici", cioè testano un singolo risultato o parametro di stato risultante da una specfica e quanto più breve possibile, sequenza di operazioni che mi faccia passare a quello stato da uno stato già testato)

2) Se devo scrivere codice per un test che ho pensato, in teoria non sono già a conoscenza del codice corretto per farlo passare e quindi potrei risparmiarmi il test?

uhm, in un certo senso sì.. ma in realtà tieni presente che il codice che hai in mente per l' implementazione, non sempre è l' unico possibile, nè il più semplice possibile

seguendo il principio del passo più breve, la prima implementazione dovrebbe essere quella del codice più semplice che fa passare il test
è molto probabile che esista una soluzione (al test) più elegante o più efficiente, quella verrà eventualmente implementata rifattorizzando in un secondo tempo, quando cioè le specifiche di funzionamento espresse nel test saranno state soddisfatte (con del codice comunque corretto)

Non mangiatemi vivo...

ma figurati, è un dubbio naturale - anzi sono contento che lo abbia esposto (diciamo che aspettavo che lo facessi

Originariamente inviato da thebol

...

-i test aiutano quando si va a modificare un pezzo di codice(refactoring o altro), perchè verificano il mantenimento della funzionalita verificata da quel test. Se si è introdotto un bug, c'è buona probabilità(non la certezza) che qualche test fallisca, e ciò rende piu facile la manutenzione.

infatti... in più una cosa che se non ricordo male, fek ripeteva spesso, è proprio che nel caso ottimale del TDD puro, nessuna modifica al codice potrebbe passare inosservata (perchè producendo uno stato diverso, farebbe fallire almeno un test)
questo però avviene se la copertura del codice da parte dei test è completa

Sono inoltre molto comodi quando si affronta qualcosa di nuovo, perchè si è obbligati ad andare passo passo, e si commettono (in media) meno errori. Quando invece si lavora su costrutti e funzioni che si conoscono molto bene, alcuni tendono a scrivere test meno pesantemente, avendo più sicurezza in quel che si fa.

infatti ... e questo, anche se può andare bene in progetti a cui partecipino pochi developers o uno solo, rischia di essere uno svantaggio per team in cui coesistano membri più e altri meno, esperti
quelli meno esperti, privi della conoscenza e della sicurezza degli altri, saranno più esposti al rischio di errori in quanto i test,, meno esaustivi, saranno meno d' aiuto nel consentirgli di rilevarli...

per maggiori delucidazioni sui pro e i contro, c'è il libro TDD: Test Driven Development di Kent Beck ( )