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...

Oddio cosa ho scritto. Ma in fondo è solo la pura verità. Stuzzicato dal post di Raffaele non ho potuto trattenermi dal postare anch'io e spendere 2 parole sull'argomento. Al mio commento Raffaele ha risposto : "Unit Testing non può essere una base per validare un software. È solo uno dei tanti sistemi che può rivelarsi più o meno utile a seconda dei casi" Io qui ribatto con: Sicuramente usare solo unit test non basta, ma se parliamo di test ce ne sono diversi tipi e riuscire ad automatizzarli invece che affidarsi ad un tester ha dei vantaggi oggettivi. Certamente non sempre è una attività...