Newsgroup: it.comp.dotnet
Titolo: Distruttori e Dispose

Buongiorno a tutti,
sto testando una classe che implementa un agente che ogni tot secondi 
lancia un job. Fin qui nulla di trascendentale. Il problema è: come 
faccio a testare il distruttore? MI spiego meglio:
class Foo : IDisposable
{
	public Foo() { ... }
	~Foo()
	{
		this.Dispose();
	}
	upblic void Dispose() { ... }
}
Di fatto, il distruttore si limita a richiamare Dispose() quindi nel 
caso specifico basta richiamare il dispose. Ora, se dovessi modificare 
il mio distruttore inserendo ulteriore codice, come potrei fare?
Grazie in anticipo e buona giornata,
Giulio
-- 

 caso specifico basta richiamare il dispose. 
Se ho capito bene il problema, forse sei fuori strada perchè in c# il
distruttore non è deterministico come in c++, ma viene richiamato
automaticamente: in altre parole si potrebbe dire che è "decorativo" ;-)

 automaticamente: in altre parole si potrebbe dire che è "decorativo" ;-)
quoto e aggiungo che viene pure eseguito su un thread differente con 
tutto quello che ne può conseguire (specie se si usa com ma non solo).
Come tutte le cose ci sono scenari che non si possono coprire e i test 
automatizzati non si esimono da questi problemi.
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 automatizzati non si esimono da questi problemi.
Ecco, questa è una di quelle cose che so che ci sono ma faccio di tutto 
per ignorare! :-) Scherzi a parte, il mio problema è che nel distruttore 
dell'oggetto in questione viene richiamato - ad esempio - il Dispose() 
su un componente dell'oggetto.
In uno scenario di test, se l'oggetto in questione e mockato, il 
distruttore viene richiamato al TearDown, ossìa *dopo* che sono state 
verificate tutte le expectations. L'alternativa è quella di non inserire 
una expectation sulla dispose del componente mockato, ma così facendo 
NUnit "scoppia" dopo che il test è passato.
Insomma: una bella rogna. :-)
(Che ovviamente si risolve usando un fake scritto a mano e non un 
oggetto mockato con Rhino Mocks, ma tanto valeva verificare la 
possibilità di una via meno dispendiosa)
Ciao,
Giulio
-- 

 meno dispendiosa)
E ne vale la pena di fare tutto questo giro?
Meglio allora limitare il test alla parte 'core' e poi un coded ui 
testing sulla distanza per verificare la stabilità e la "quota" di 
memoria, handle, etc. per verificare eventuali leak.
Meno tempo developer, migliori risultati ... altrimenti il test rischia 
di essere una mania compulsiva :D


 di essere una mania compulsiva :D
Guarda... a lungo termine i migliori risultati forse non ci sono. :-)
Se impiego 2h a scrivere i test automatizzati e poi a ogni modifica devo 
verificare la non regressione con mille-mila ore di test "a mano"... ci 
ho guadagnato? ;-) (ah... questo è un *tipico* ragionamento da 
manager!!! :-ppp)
Ciao,
Giulio
-- 

 guadagnato? ;-) (ah... questo è un *tipico* ragionamento da manager!!! :-ppp)
Stai dando per scontato che i test ti coprano tutti gli scenari e 
questo è quasi sempre clamorosamente falso se l'applicazione è 
complessa :)
Unit testing è uno strumento valido per scenari circoscrivibili dove il 
numero di variabili in ingresso e uscita è predeterminabile in un 
intervallo decente (il tipico esempio è il controllo di un algoritmo di 
parsing).
Ma quando il campo si allarga allora è molto più attendibile un test 
sulle funzionalità nel globale, cosa che puoi automatizzare con il 
coded-ui testing che serve proprio a testare scenari reali di utilizzo.
(tanto per capirci, nessuno dei due è mutualmente esclusivo)


 coded-ui testing che serve proprio a testare scenari reali di utilizzo.
Il coded-ui testing non lo conosco: mi documenterò.
Ma se per UI si intende "user interface" sarà dura, visto che il codice 
che devo testare è quello di un demone che se ne sta nascosto a fare il 
suo sporco lavoro. :-)
Ciao e grazie,
Giulio
-- 

 sporco lavoro. :-)
Si, sta per UI. L'equivalente per un daemon è il test del suo 
funzionamento a "scatola chiusa". Cioè riprodurre uno scenario reale 
dove testi il globale e non le singole funzionalità.
(il che non esclude certamente l'utilità di unit testing laddove questo 
sia pratico applicarlo)
Ciao


 dove testi il globale e non le singole funzionalità.
Capito.


 Giulio
Ciao!


 ovvio cosa faccia leggendo il codice.
Mai usato MEF.
Dici che è ora di iniziare? ;-)
Ciao e buona giornata,
Giulio
-- 

 Giulio
Ciao
