Design Guidelines
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...
Che differenza c'è tra queste due eccezioni? Chi meglio di Brad Abrams può spiegarcelo!
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
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....:)
Questa è una delle "Ten Rules of Performaces" scritte da Paul Vick nel suo blog. C'è sempre da imparare... :)