Newsgroup: it.comp.lang.c++
Titolo: TDD : quanti ne fanno uso?

Mi sto interessando al test driven development in C++: non avendo 
tuttavia alcuna esperienza diretta, vorrei sapere se qualcuno di voi 
l'ha provata, e come si ï¿œ trovato.
E' una metodologia efficace? Dove ha migliorato le vostre condizioni di 
sviluppo?
Oppure si usa solo in java e .net ?
Saluti

 Oppure si usa solo in java e .net ?
Non vedo perche' il linguaggio dovrebbe fare differenza.
  bye
	av.

 Oppure si usa solo in java e .net ?
No.
-- 
Carlo Milanesi
http://digilander.libero.it/carlmila

 Se ne esce una discussione interessante, ben venga :-)
IMHO stai confondendo unit test e TDD. Per fare TDD usi gli unit-test,
ma il TDD e' una metodologia di sviluppo, gli unit-test una tecnica di
testing. In teoria puoi usare gli unit-test senza fare TDD. Io
personalmente trovo che venga molto peggio.
Le situazioni in cui li ho trovati utili sono una percentuale
elevatissima delle situazioni che ho affrontato. Quando non so come
affrontare, mi sento a disagio: sento che mi servirebbero.
-- 
-riko

 Oppure si usa solo in java e .net ?
Generalmente piu' l'ambiente e' moderno piu' e' facile che sia
utilizzato. Piu' il tutto e' dinamico e c'e' introspezione e piu' facile
che sia usato. Questo all'interno dei linguaggi imperativi/ad oggetti.
-- 
-riko

 abbia provato (C puro escluso).
Questo non è un incoraggiamento, però.. :-)
Cmq, vedendo poi i fatti che mi hai raccontato, il TDD in c++ è uno 
sforzo che ripaga,alla lunga, il tempo impiegato per scrivere i test.
Ho capito bene quello che hai scritto?
Ciao

 affrontare, mi sento a disagio: sento che mi servirebbero.
Su quest'ultimo punto siamo d'accordo; detto in altro modo: quando vedo 
che gli UnitTest/TDD non vanno bene, mi sento a disagio e mi chiedo se 
esiste qualcosa d'altro che potrebbe sostituirli.
  bye
	av.

 affrontare, mi sento a disagio: sento che mi servirebbero.
Questo mi fa piacere sentirlo dire, è proprio l'epserienza che deve 
dire se una metodologia ti aiuta o meno.
Ciao

 lavorando).
Qui trovi un bellissimo post:
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle
l'ho stampato e me lo sono ben studiato: aiuta a capire i frameworks e 
l'applicazione del TDD.
Ciao

 esiste qualcosa d'altro che potrebbe sostituirli.
Se hai tempo, capacita' e il problema si presta, dimostrazioni di
correttezza formale. Buona fortuna. ;)
-- 
-riko

 Ho capito bene quello che hai scritto?
Allora: senza test non vai da nessuna parte. Posso spingermi a dire che
essenzialmente e' un caso se il sw funziona. Tutte le metodologie di
sviluppo prevedono dei test.
Questo veniva fatto tipicamente nei progetti "seri", ma non a livello
amatoriale. Per motivi di cultura, ignoranza, necessita'.
Il TDD essenzialmente "irrompe" nella cultura comune con l'enfasi sui
test (che e' aumentata anche in metodologie non agili, che si sono
sempre piu' mosse verso test-early). Il TDD e' anche e soprattutto una
metodologia di sviluppo e di progettazione, *non* di testing. 
Quindi, in teoria, il tempo per scriver i test lo pagheresti comunque
(perche' i test li scriveresti comuneque, o peggio faresti a mano le
prove -- che e' una cosa che i principianti fanno, ma e'
*allucinante*[0]).
Il TDD ti aiuta a scrivere codice che sia testabile. Se hai una base di
codice di schifo, c'e' anche il caso che *non* sia essenzialemnte
testabile, lo sia in parte o lo sia malamente. Anche in codice decente,
spesso scrivere i test a posteriori e' piuttosto noioso perche' ti rendi
conto che mancano applicazioni di DIP non strettamente necessarie per il
codice "corrente" ma che potrebbero essere preziosissime per evoluzioni
future (e sono indispensabili per i test).
Questo in teoria. 
In pratica in C++ hai sia il problema della compilazione (che rallenta),
dello static typing (che costringe a mettere un sacco di codice per
rendere contento il compilatore in ordine un pochetto innaturale per
compilare) *e* della completa mancanza di introspezione, che ti
costringe a ripeterti (violando DRY).
In Java, per esempio, hai il primo problema mitigato da molti IDE (tanto
che quasi non te ne accorgi), il secondo pure mitigato (grazie alle
varie code generations) e il terzo dal linguaggio e dai framework.
Personalmente trovo JUnit ordini di grandezza piu' comoda di Boost::Test
(o come ceppa si chiama).
In Python i problemi di cui sopra addirittura non esistono, e vinci
addirittura un'interprete interattivo per provare le cose, per cui se
non fai TDD stretto, puoi comunque farti test automatizzati gratis a
partire da quelli manuali.
Il mio consiglio? TDD, comunque. O per lo meno testing. Non si scappa.
C++ e' meno comodo? Amen. Se lo usi, avrai un buon motivo, per cui non
ci scappi comunque. 
-- 
-riko

Ciao a tutti,
riporto la mia esperienza circa del codice C++ scritto all'inizio
della mia carriera (98), ben poco OO, il cui scopo era sostanzialmente
elaborazione di segnale; una situazione presumo molto simile a quella
di Andrea Venturoli, in cui entrano in gioco mesh triangolari
tridimensionali da sezionare, curve da intersecare, baricentri di
intersezioni da determinare, per ottenere una forma d'onda che andava
successivamente opportunamente trattata prima di estrapolare una
decina di parametri caratteristici.
Premetto che l'approccio è piuttosto pragmatico...
Nel momento in cui è stato richiesto un intervento piuttosto pesante
al codice (e dopo diversi anni di esperienza), ho deciso di
abbracciare la filosofia dei test. Dovendo partire da una base di
codice esistente, non ho ovviamente lavorato in TDD, ove si presume
che i test indirizzino la progettazione, nè test first, in cui, anche
avendo un'architettura in mente, parti comunque dai test.
Ho deciso comunque di fotografare il codice esistente (il cui
funzionamento il cliente riteneva soddisfacente), e cristallizzarlo
con una serie di test funzionali: data questa acquisizione, mi aspetto
questi parametri. Intendo dire che inizialmente salvavo su file di
testo i valori floating point ottenuti e lo confrontavo con i file
campione. Questo per me è stato il passo fondamentale per
intraprendere una fase di refactoring a cuor leggero, sicuro che gli
interventi che operavo non modificavano il comportamento
dell'algoritmo.
Nel tempo ho avuto modo di partizionare il codice iniziale in un
insieme di liberie, gran parte di esse realizzate in modalità TDD/test-
first; lanciare lo script di build e veder scorrere sulla console
tutti quei "TestXXX... passed!" ti dà una soddisfazione! Senza
tralasciare il fatto che ho potuto anche verificare che il codice di
partenza conteneva un numero non trascurabile di bachi.
Ancora adesso, al termine del build faccio girare i test "globali"
originali. In tutta sincertità, al momento percepisco due "smells" in
questo modo di lavorare (e per questo progetto specifico): se per
qualche motivo il cliente mi chiede di modificare l'algortimo, devo
rigenerare e validare i file campione; in secondo luogo, contenendo i
file campione dei valori floating point, mi capita di dover utilizzare
dei file campioni diversificati in funzione dei compilatori utilizzati
(VC/GCC) e delle relative parametrizzazioni (DEBUG/RELEASE per dirne
una).
A quanto già detto da Enrico, posso aggiungere che l'uso di una suite
di unit-test ti farà dimenticare di avere installato un debugger...
Ciao,
Gianfranco