Newsgroup: it.comp.dotnet
Titolo: [TDD] Sviluppo TDD con C#

Salve a tutti, non so se vado leggermente OT, ma succede che mi sto 
ponendo problemi di scope cercando di sviluppare seguendo un approccio 
test driven.
Quello che mi sono chiesto quasi subito è come si concilia 
l'incapsulamento con la necessità di scrivere test per metodi testabili, 
dunque necessariamente pubblici.
Faccio un esempio pratico:
sto lavorando a un progetto che prevede il postprocessing di una serie 
di files xml da parte di una serie di plugin, dunque abbiamo delle 
classi che implementano un'interfaccia IPlugin che espone due metodi:
Init e Execute.
Uno di questi plugin deve leggere in una cartella, cercare determinati 
files xml, parsarli cercando al loro interno alcuni path di ALTRI files, 
costruire una lista di questi ultimi e passarli a un tool che li 
processa esternamente.
Pensando TDD, dovrei scrivere per prima cosa i test per i metodi che 
fanno tutte quelle operazioni, ma quei metodi dovrebbero essere 
nascosti, visto che il plugin espone solo due metodi.
E' dunque necessario esporre _tutti_ i metodi da testare, rompendo 
l'incapsulamento "logico" della classe? Cosa ne pensate? O sto 
sbagliando a interpretare il TDD?
Grazie e ciao

 interpretare il TDD?
 
una considerazione filosofica: perché è un problema che sia tutto 
"public" (sia chiaro che per me lo è eccome)
 
Dai un occhio all'attributo InternalsVisibleTo
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 sbagliando a interpretare il TDD?
 
Io imposterei ogni test in questo modo:
1. set-up dell'ambiente esterno (crei dei files .xml ad hoc, con dentro 
i path ad altri files sempre ad hoc, ecc ecc...)
2. lanci il plug-in
3. se l'esecuzione è andata a buon fine, il plug-in avrà avuto il suo 
effetto sul "mondo esterno", e l'assertion del test deve misurare 
proprio che questo effetto sia avvenuto.
 
Niente test dell'implementazione.
:-)
 
Ciao,
Giulio
 
-- 
 
 
 

 Dai un occhio all'attributo InternalsVisibleTo
grazie, funziona, a parte il fatto che devo usare internal nella 
dichiarazione dei metodi (mentre avrei usato private che non è la stessa 
cosa) va benissimo e prenderò anche questa strada.
Poi col mio collega di pair abbiamo anche deciso di esternalizzare un 
componente che racchiude alcuni dei metodi privati e renderlo pubblico e 
testabile, ma non posso farlo con tutto.
Ciao!
 

 Niente test dell'implementazione.
 
Eh come ci dicevamo ieri "live", il problema presenta diverse sfumature, 
diciamo che a tendere il tuo approccio è il più "desiderabile", ma 
durante uno sviluppo from scratch il TDD ti dovrebbe aiutare proprio a 
sviluppare, quindi proprio "tirare su", anche l'interno della black box, 
dunque come fare? L'internalsVisibleTo mi sembra un buon compromesso.
Ciao!

 dunque renderli pubblici solo perché ci sono i test
 
Come suggerito da Mauro, l'approccio internal+[InternalsVisibleTo] è
quello maggiormente consigliato (ovviamente, trattandosi di Mauro ;-)
)... possono poi essere usati (con minore potenza) l'attributo
condizionale [Debug] oppure l'espressione #if #endif con la compilazione
condizionale (il libro per me cult al riguardo è "The Art of Unit Test"
di Roy Osherove: trovi tutte e 3 le strade lì se hai voglia di
approfondire).
 
Piuttosto, l'unica cosa che non mi torna è l'affermazione che ho
quotato: se devi rendere pubblici dei metodi solo perché devi fare
unit-testing, per me, vuol dire che la responsabilità di fare quelle
cose, deve spettare a un'altra classe, che poi verrà usata privatamente
dal plugin che espone solo i 2 metodi pubblici Init e Execute...
 
Ciao.

 di Roy Osherove
grazie, ce l'avevo ma gli ho preferito "TDD by example" di Kent Beck che 
però non mi ha entusiasmato tantissimo. Gli darò presto un'occhiata, 
grazie ancora
 
Ciao

 Ciao.
