Stasera mentre leggevo un post sulla mailing-list extremeprogramming-it ho letto un passaggio che condivido pienamente e che quindi mi permetto di riportare qui: .... per una società che si occupa di sviluppo software l'attività con il maggior ritorno economico è la selezione del personale e la crescita delle persone al suo interno, quindi su questo dovrebbero aversi i maggiori investimenti e a questo dovrebbero essere assegnate le persone più affidabili.Là dove una fabbrica di automobili da per scontato un grosso investimento per acquisire la tecnologia e il macchinario necessari, una software-house deve dare per scontato un grosso sforzo ed esborsonell'acquisizione...

Oggi, facendo alcune prove suggerite da questo post di Antonio, ho notato che nell'assembly MbUnit.Framework.2.0 è disponibile la classe Reflector che serve per controllare lo stato di un oggetto tramite reflection in maniera molto semplice. Per esempio: [Test]public void Ctor_Always_SetFieldName(){    Foo foo = new Foo("claudio");    Assert.AreEqual("claudio", Reflector.GetField(foo, "_name"));} serve per controllare che il costruttore imposti correttamente il valore della variabile di classe che si chiama _name. Ovvero che Foo sia così: public class Foo{    private readonly string _name;     public Foo(string name)    {        _name = name;    }} Anche se generalmente un test non controlla lo stato interno di un'oggetto...

Solitamente quando scrivo un metodo di test cerco di dargli un nome che sia riassuntivo per il codice che sto andando a testare di modo che un domani quando ci ritornerò per qualsiasi motivo mi basterà leggerne il nome per capire che test viene eseguito al suo interno. Guardando in giro vedo che sul web più o meno questo è quello che fanno tutti gli "adepti" dello unit-test. Quest'anno al TechEd, Roy Osherove ha suggerito questo pattern per dare un nome ai metodi di test:         NomeMetodo_Condizione_Comportamento visto che mi sembrava cosa buone e giusta, ho aggiornato il mio template...

Dopo gli esperimenti realizzati l'inverno scorso e le positive discussioni che hanno seguito l'open space di quest'anno all'agileday  abbiamo deciso di dare il via ad una serie di chat "tecnologiche". Dal sondaggio effettuato sulla lista risulta che la data preferita è 10 Dicembre. Quindi è confermato che ci troviamo online su GTalk alle 21.00 . I temi che tratteremo saranno: cos'è ALT.NET quali strumenti e quali metodologie usiamo progetti del gruppo? (incontri veri a gennaio e progetto open source) L'iniziativa è aperta a tutti, e tutti potranno parlare ed esprimere opinioni, consigli, esperienze,...