mercoledì 8 luglio 2009
mercoledì 16 aprile 2008
TypeMock ed i costruttori statici
Ultimamente mi sono imbattuto in un problema di TypeMock veramente subdolo. Lo scenario e' il seguente: supponete di avere una classe X, dotata di costruttore statico (dove, ad esempio, viene inizializzato un membro statico, come un hash o un array).
Supponete di scrivere una fixture dove la classe X viene mockizzata. Supponete poi di scrivere una fixture che testa proprio la classe X. Ebbene, se l'ordine di esecuzione e' questo, allora la seconda fixture probabilmente fallira'.
A quanto pare, TypeMock in qualche modo provoca l'esecuzione del costruttore statico al momento della mockizzazione (cosa usualmente non richiesta) ma, quando poi viene instanziato un oggetto della classe X per la prima volta tale costruttore non viene piu' richiamato. Il problema e' veramente subdolo, poiche' il successo o fallimento dei test dipende dall'ordine di esecuzione dei test.
Fortunatamente, c'e' la soluzione. Basta dire a TypeMock di non mockizzare il costruttore statico, cosi:
MockManager.Mock(typeof(X), Constructor.StaticNotMocked);
Supponete di scrivere una fixture dove la classe X viene mockizzata. Supponete poi di scrivere una fixture che testa proprio la classe X. Ebbene, se l'ordine di esecuzione e' questo, allora la seconda fixture probabilmente fallira'.
A quanto pare, TypeMock in qualche modo provoca l'esecuzione del costruttore statico al momento della mockizzazione (cosa usualmente non richiesta) ma, quando poi viene instanziato un oggetto della classe X per la prima volta tale costruttore non viene piu' richiamato. Il problema e' veramente subdolo, poiche' il successo o fallimento dei test dipende dall'ordine di esecuzione dei test.
Fortunatamente, c'e' la soluzione. Basta dire a TypeMock di non mockizzare il costruttore statico, cosi:
MockManager.Mock(typeof(X), Constructor.StaticNotMocked);
lunedì 17 marzo 2008
C# e gli strumenti di code coverage
Ultimamente vi e' un'accesa discussione su questo argomento, dal momento che nel mondo C# i tool free non abbondano... In pratica, da quando NCover e' diventato commerciale, molti sviluppatori si sono interrogati su quale strumento free utilizzare per eseguire il code coverage dei propri test.
Personalmente, utilizzo da diverso tempo NCover 1.5.8 con soddisfazione e non credo che passero' mai alla versione commerciale (che tuttavia non costa moltissimo, circa 150 USD).
D'altro canto sembra che molti sviluppatori si stiano convertendo all'utilizzo di un altro strumento free, PartCover, come ad esempio la communit di SharpDevelop.
Tuttavia, lo stato del progetto su soruce forge non e' molto incoraggiante, in quanto non sembra esserci molta attivita' al riguardo. Inoltre, altra cosa fastidiosa, TypeMock non supporta esplicitamente PartCover, e questo puo' essere un bel freno inibitore per coloro che utilizzano appunto TypeMock.
Personalmente, utilizzo da diverso tempo NCover 1.5.8 con soddisfazione e non credo che passero' mai alla versione commerciale (che tuttavia non costa moltissimo, circa 150 USD).
D'altro canto sembra che molti sviluppatori si stiano convertendo all'utilizzo di un altro strumento free, PartCover, come ad esempio la communit di SharpDevelop.
Tuttavia, lo stato del progetto su soruce forge non e' molto incoraggiante, in quanto non sembra esserci molta attivita' al riguardo. Inoltre, altra cosa fastidiosa, TypeMock non supporta esplicitamente PartCover, e questo puo' essere un bel freno inibitore per coloro che utilizzano appunto TypeMock.
giovedì 17 gennaio 2008
Ron Gilbert alla riscossa!
Anche se non e' un post dedicato ai soliti argomenti, penso sia cmq di elevato interesse per le persone della mia generazione (e non!). Ron Gilbert, mitico autore delle avventure grafiche Monkey Island 1 e 2, ha appena annunciato l'uscita del suo ultimo lavoro: DeahtSpank! Sono proprio curioso di vederlo, per vedere se il buon vecchio Ron ha mantenuto il suo ineffabile tocco magico...
martedì 15 gennaio 2008
Dependency injection e TypeMock
Negli ultimi tempi c'e' stata un'accesa discussione su DI e TypeMock, scatenata dal creatore di TypeMock stesso.
Sebbene sia un utente molto felice di TypeMock, non credo che si possa considerare una totale alternativa alla DI. E' vero che questo principio, guidato dalla scrittura di unit tests, puo' portare a creare del codice ad hoc per il testing, ma e' anche vero che uno dei maggiori benefici della DI e' quello di abbassare il livello di coupling tra classi.
Per non parlare inoltre del vantaggio implicito dato dalla scrittura di un'interfaccia. Bypassare completamente la DI a favore di TypeMock puo' portare ad un altro svantaggio, che e' innato con la natura dei mock: si rischia di scrivere dei test che conoscono "troppo" i dettagli interni della classe testata.
Cio' normalmente non accade con l'uso di interfaccie, in quanto i fake scritti risultano (nella maggior parte dei casi) delle classi molto stupide e semplici. Quindi, in definitiva, si' a TypeMock come strumento odierno di lavoro, ma no come sostituto totale della DI.
Sebbene sia un utente molto felice di TypeMock, non credo che si possa considerare una totale alternativa alla DI. E' vero che questo principio, guidato dalla scrittura di unit tests, puo' portare a creare del codice ad hoc per il testing, ma e' anche vero che uno dei maggiori benefici della DI e' quello di abbassare il livello di coupling tra classi.
Per non parlare inoltre del vantaggio implicito dato dalla scrittura di un'interfaccia. Bypassare completamente la DI a favore di TypeMock puo' portare ad un altro svantaggio, che e' innato con la natura dei mock: si rischia di scrivere dei test che conoscono "troppo" i dettagli interni della classe testata.
Cio' normalmente non accade con l'uso di interfaccie, in quanto i fake scritti risultano (nella maggior parte dei casi) delle classi molto stupide e semplici. Quindi, in definitiva, si' a TypeMock come strumento odierno di lavoro, ma no come sostituto totale della DI.
lunedì 19 novembre 2007
Power of Two Games
Un brevissimo update relativo al precedente post. In realta', il blog a cui mi riferivo, continua a vivere qui (Power of Two Games). Anche se non postano molto articoli estremamente tecnici, risulta sempre un'interessante lettura.
lunedì 22 ottobre 2007
TDD e game development
Questo blog, purtroppo da diverso tempo non piu' aggiornato, contiene un'interessante serie di articoli inerenti al TDD applicato al settore dei videogiochi. Guardando un po' a giro, la mia impressione e' che questa metodologia prenda sempre piu' piede anche nel settore del game development.
Iscriviti a:
Post (Atom)