Design Guidelines

Assert multipli all'interno di un singolo unit test

Gianluca Carucci — Wed, 04 Oct 2006 10:48:00 GMT

Roy Osherove fornisce in questo post, alcuni validi motivi del perchè secondo lui non dovrebbe essere possibile permettere di fallire più assert nell'esecuzione di un singolo unit test. Il post è in contrapposizione con un'altro post di James Avery dove viene spiegato invece, il perchè questa feature potrebbe essere utile.

Un piccolo assaggio che quoto in pieno:

"Even if we assume that all the asserts are run, you're essentially running multiple tests on code that has "dirty" state. For example, asserting on the result of a method call may actually change the state of the object under test so that the next call to that method may actually be skewed because of the previous asserts. that's a bad world to be in. having single assert per test means you also know exactly the state of your object before the assert."

Technorati tags: UnitTest, TDD, Agile, Assert, assert

NotSupportedException e NotImplementedException

Gianluca Carucci — Fri, 30 Jul 2004 10:26:00 GMT

Che differenza c'è tra queste due eccezioni? Chi meglio di Brad Abrams può spiegarcelo!

IPEndPoint.Create(SocketAddress), perchè è un Instance Method????

Gianluca Carucci — Tue, 27 Jul 2004 16:28:00 GMT

Evidentemente non sono l'unico a essermi fatto questa domanda....

Dando un'occhiata al codice di Mono, nell'implementazione della proprietà LocalEndPoint e RemoteEndPoint si può notare il seguente codice (e i commenti) :

"...

if(sa.Family==AddressFamily.InterNetwork || sa.Family==AddressFamily.InterNetworkV6 ) {

// Stupidly, EndPoint.Create() is an

// instance method

return new IPEndPoint(0, 0).Create(sa);

}

..."

Chissà se chi ha progettato (o implementato) la classe IPEndPoint lavora ancora in Microsoft:P

Qualche linea guida di design di librerie

Gianluca Carucci — Wed, 21 Apr 2004 12:37:00 GMT

Segnalo qualche post del blog di Brad Abrams in cui vengono elencate alcune (OTTIME) regole da tenere presente nella costruzione delle classi. Da stampare e attaccare sopra il monitor:)

On Designing Good Libraries -- Part I

On Designing Good Libraries -- Part II

On Designing Good Libraries -- Part III

On Designing Good Libraries -- Part IV

E se non vi bastasse.... c'è sempre questa serie di articoli sull'MSDN...

Buon Refactoring....:)

Il 90% dei problemi di performance sono nel design non nel codice

Gianluca Carucci — Thu, 12 Feb 2004 10:25:00 GMT

Questa è una delle "Ten Rules of Performaces" scritte da Paul Vick nel suo blog. C'è sempre da imparare... :)