Invest in people before investing in tools

Google Testing Blog - Clean Code Talks

Matteo Baglini — Tue, 02 Dec 2008 15:17:13 GMT

Chiunque di voi scriva test unitari per il proprio codice (perché esiste ancora qualcuno che non lo fa?? ) consiglio questi brevi video di Google:

Clean Code Talks - Unit Testing

Clean Code Talks - Dependency Injection

Clean Code Talks - Global State and Singletons

Technorati Tag: UnitTest,DependencyInjection,Pattern

Pattern Model-View-ViewModel, INotifyPropertyChanged, Static Reflection e Extension methods

Matteo Baglini — Fri, 28 Nov 2008 14:06:28 GMT

Anch’io nei miei progetti WPF per rendere testabile la logica della mia applicazione senza rinunciare alla pontenza del DataBinding utilizzo (anche) il Pattern Model-View-ViewModel. L’interfaccia INotifyPropertyChanged gioca un ruolo fondamentale nell’implementazione di questo pattern quindi ne faccio un uso massiccio. Quello che non mi è mai piaciuto di questa interfaccia è l’uso delle stringe per indicare qual è la proprietà modificata, vediamo un semplice esempio dell’uso di INotifyPropertyChanged:

   1:  public class Person : INotifyPropertyChanged {

   2:    public event PropertyChangedEventHandler PropertyChanged;

3:

   4:    private string firstName = String.Empty;

   5:    public string FirstName {

   6:      get { return firstName; }

   7:      set {

   8:        if (firstName != value) {

   9:          firstName = value;

  10:          RaisePropertyChanged("FirstName");

  11:        }

  12:      }

  13:    }

14:

  15:    private void RaisePropertyChanged(string propertyName) {

  16:      if (PropertyChanged != null)

  17:        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

  18:    }

  19:  }

Se cambio il nome della proprietà FirstName Visual Studio si accorge del cambiamento e mi permette con un solo click di rinominare la proprietà ovunque venga utilizzata, però questo sistema di refactoring non è abbastanza smart da modificare la stringa FirstName (riga 10). Grazie alla Static Reflection possiamo eliminare questo problema, il “trucco” sta nel passare al metodo RaisePropertyChanged la proprietà come tipo Expression<Func<T>>, convertire successivamente il Body nel tipo MemberExpression ed in fine recuperare il nome tramite le proprietà Member. Risultato:

   1:  public class Person : INotifyPropertyChanged {

   2:    public event PropertyChangedEventHandler PropertyChanged;

3:

   4:    private string firstName = String.Empty;

   5:    public string FirstName {

   6:      get { return firstName; }

   7:      set {

   8:        if (firstName != value) {

   9:          firstName = value;

  10:          RaisePropertyChanged(() => FirstName);

  11:        }

  12:      }

  13:    }

14:

  15:    private void RaisePropertyChanged<T>(Expression<Func<T>> property) {

  16:      var expression = property.Body as MemberExpression;

  17:      var member = expression.Member;

  18:      if (PropertyChanged != null)

  19:        PropertyChanged(this, new PropertyChangedEventArgs(member.Name));

  20:    }

  21:  }

Adesso il nostro codice supporta pienamente il rename refactoring. Come ultimo passo possiamo incapsulare la logica di manipolazione dei tipi Expression in un Extension methods rendendo il codice molto più leggibile:

   1:  public static class PropertyExtensions {

   2:    public static PropertyChangedEventArgs CreateChangeEventArgs<T>(this Expression<Func<T>> property) {

   3:      var expression = property.Body as MemberExpression;

   4:      var member = expression.Member;

   5:      return new PropertyChangedEventArgs(member.Name);

   6:    }

   7:  }

8:

   9:  public class Person : INotifyPropertyChanged {

  10:    public event PropertyChangedEventHandler PropertyChanged;

11:

  12:    private string firstName = String.Empty;

  13:    public string FirstName {

  14:      get { return firstName; }

  15:      set {

  16:        if (firstName != value) {

  17:          firstName = value;

  18:          RaisePropertyChanged(() => FirstName);

  19:        }

  20:      }

  21:    }

22:

  23:    private void RaisePropertyChanged<T>(Expression<Func<T>> property) {

  24:      if (PropertyChanged != null)

  25:        PropertyChanged(this, property.CreateChangeEventArgs());

  26:    }

  27:  }

Technorati Tag: Model-View-ViewModel,M-V-VM,Extension Methods,INotifyPropertyChanged,Expression

WPF Effects Library

Matteo Baglini — Thu, 23 Oct 2008 07:47:00 GMT

Una delle novità di WPF 3.5 SP1 sono gli Shader Effects, adesso il Team di WPF ha pubblicato su CodePlex la Windows Presentation Foundation Pixel Shader Effects Library, una libreria contenente molti Shader Effects, direttamente dalla home del progetto:

Initial seed includes:
Effects:
BandedSwirl, Bloom, BrightExtract, ColorKeyAlpha, ColorTone, ContrastAdjust, DirectionalBlur, Embossed, Gloom, GrowablePoissonDiskEffect, InvertColor, LightStreak, Magnify, Monochrome, Pinch, Pixelate, Ripple, Sharpen, SmoothMagnify, Swirl, Tone, Toon, and ZoomBlur
Transition Effects:
BandedSwirl, Blings, Blood, CircleReveal, CircleStretch, CircularBlur, CloudReveral, Cloudy, Crumble, Dissolve, DropFade, Fade, LeastBright, LineReveal, MostBright, PixelateIn, PixelateOut, Pixelate, RadialBlur, RadialWiggle, RandomCircleReveal, Ripple, Rotate, Saturate, Shrink, SlideIn, SmoothSwirl, Swirl, Water, Wave.

Ora non resta che provarli tutti .

Technorati Tag: WPF,Windows Presentation Foundation,Shader Effects

Pubblicati i sorgenti del controllo WatermarkedTextBox

Matteo Baglini — Wed, 22 Oct 2008 19:27:00 GMT

Fra i vari controlli presenti nelle prime versioni di Silverlight c’era la WatermarkedTextBox. Dalla release Beta2 tale controllo è stato rimosso. Adesso, pressati dalle forti richieste, il team di Silverlight ha rilasciato il codice sorgente del suddetto controllo.

Sorgenti: WatermarkedTextBox-Source.zip
Binari: WatermarkedTextBox-Binary.zip

Fonte: Silverlight 2 Watermarked TextBox Control

Technorati Tag: Silverlight

[WPF] Intercettare l’evento MouseDoubleClick di un ListBoxItem

Matteo Baglini — Wed, 22 Oct 2008 19:27:00 GMT

Visual Studio 2008 Sp1 non visualizza l’evento MouseDoubleClick per un ListBoxITem, come se non esistesse:

In realtà tale evento esiste, è solo un problema di IntelliSense, quindi basta digitare il nome e tutto funziona:

Al seguente url è disponibile una piccola demo: ListItemDoubleClickDemo

Technorati Tag: WPF,Windows Presentation Foundation

XAML - differenze fra Silverlight e WPF

Matteo Baglini — Wed, 22 Oct 2008 19:14:00 GMT

XAML è un linguaggio dichiarativo general-purpose, sviluppato da Microsoft e derivato dall’XML, atto alla rappresentazione di gerarchie di oggetti. Attualmente XAML è utilizzato in Silverlight, Windows Presentation Foundation (WPF) e Windows Workflow Foundation (WF), ognuno con il proprio parser e runtime. Sul sito MSDN possiamo trovare un articolo che spiega le differenze fra il parser di Silverlight e quello di WPF.

Technorati Tag: Silverlight,WPF,Windows Presentation Foundation,XAML

[WPF] RadioButton+Binding=BUG

Matteo Baglini — Mon, 20 Oct 2008 19:22:00 GMT

Questo post doveva essere pubblicato già da po’ di settimane, ma gli impegni sono sempre pronti a mettere il bastone fra le ruote.

In WPF se mettete in Binding una proprietà di tipo boolean con un controllo RadioButton vi accorgerete presto di un bug nel motore di Binding.

Maggiori info su questo thread sul newsgroup di C#.

Grazie a Corrado per la segnalazione

Technorati Tag: Windows Presentation Foundation,WPF

Expression Blend framework vs CompositeWPF framework

Matteo Baglini — Mon, 20 Oct 2008 18:51:00 GMT

Un interessante confronto tra il framework di una WPF Composite Application (Expression Blend) e un framework per creare WPF Composite Application (CompositeWPF).

Fonte: Expression Framework versus Composite WPF

Technorati Tag: ExpressionBlend,CompositeWPF,WPF,Windows Presentation Foundation

Adesso ci siamo anche noi!!

Matteo Baglini — Mon, 20 Oct 2008 12:47:00 GMT

Non sono bravo a fare gli annunci formali quindi vado dritto al sodo, insieme ad un gruppo di amici abbiamo dato vita allo User Group Toscano su .NET, il sito è ufficialmente online da Venerdì 10 Ottobre. Alcuni di noi erano presenti alla tappa Toscana dell’evento Microsoft Days dove Pietro Brambati ha accettato la nostra proposta di sfruttare l’occasione per presentare il neonato gruppo (con tanta insistenza da parte nostra non poteva rifiutare ). Pietro si è dimostrato molto disponibile ed alla fine ha fatto molto di più di quello che abbiamo chiesto…

Sempre in quell’occasione ho avuto il piacere di conoscere Gabriele Castellani, Giuseppe Guerrasio e Alessandro Del Sole, che ringrazio e saluto!

Per finire un particolare grazie va a Paolo Carpitelli, una persona molto disponibile che, nonostante non abbia niente a che fare con il modo IT, ne tanto meno con quello delle communities, con pochissimo preavviso è stato in grado di fornirci un logo in tempo per l’evento di Giovedì, sopportando anche le nostre esigenze. Grazie Paolo!

PS: mentre UGIdotNET era off-line per i problemi che sappiamo, Marco Minerva era in totale astinenza da blogging, dato che ormai aveva perso tutti i capelli e non sopportava più quello stato di ansia e tensione ha iniziato a bloggare sulla nostra community :D

Technorati Tag: DotNetToscana

[OT] 100 Pushups challenge

Matteo Baglini — Fri, 29 Aug 2008 10:08:58 GMT

Accettare la sfida è stato facile ...però ora arriva la parte difficile, raggiungere l'obbiettivo!!

La prima fase è un test iniziale nel quale ho fatto 25 flessioni di fila!! ( + 1 infarto )

Technorati Tag: flessioni,100pushups

Usare RhinoMocks per testare applicazioni multithreading

Matteo Baglini — Mon, 25 Aug 2008 09:19:32 GMT

Interessato dal post di Antonio sull'uso del TDD per progettare applicazi multithreading ho deciso di riprovare senguendo il percorso logico da lui espresso, usando RhinoMocks come framework di mocking piuttosto che i mocks manuali usati da Antonio per non complicare il codice di test. La versione di RhinoMocks utilizzata è la 3.5 RC che potete scaricare a questo url, questa versione della libreria supporta la sintassi Arrange/Act/Assert permettendo di scrivere test molto più chiari, per maggiori info visitate questa pagina.

Adesso vediamo e commentiamo i vari metodi di test, cominciamo con il primo:

   1:  public void When_Enqueue_A_Log_The_LogWriter_Is_Invoked()

   2:  {

   3:      var log = new Log();

   4:      var writer = MockRepository.GenerateMock<ILogWriter>();

   5:      var thread = new LogThread(writer);

6:

   7:      thread.Enqueue(log);

8:

   9:      writer.AssertWasCalled(x => x.Write((Arg<Log>.Is.Equal(log))));

  10:  }

Le differenze sostaziali sono, alla riga 4 e 9, nella prima generiamo un mock dell'interfaccia ILogWriter e nella seconda "chiediamo" al mock object di verificare se è stato chiamato il metodo Write e se il parametro in ingresso era uguale a log. Proseguiamo con il secondo test:

   1:  public void The_Calls_To_The_Writer_Are_Asynchronous()

   2:  {

   3:      var log = new Log();

   4:      var writer = MockRepository.GenerateMock<ILogWriter>();

   5:      var thread = new LogThread(writer);

   6:      int writerCallCount = 0;

   7:      var resetEvent = new ManualResetEvent(false);

8:

   9:      writer.Expect(x => x.Write((Arg<Log>.Is.Anything))).Do(new Action<Log>(l =>

  10:      {

  11:          writerCallCount++;

  12:          resetEvent.WaitOne();

  13:          writerCallCount--;

  14:      }));

15:

  16:      thread.Enqueue(log);

  17:      while (writerCallCount == 0)

  18:      {

  19:          Thread.Sleep(0);

  20:      }

  21:      Assert.AreEqual(1, writerCallCount);

  22:      resetEvent.Set();

  23:  }

La parte interessante in questo test sono le righe dalla numero 9 alla 14, dove istruisco il mock object. In pratica non faccio altro che "dire" al mock object "quando viene invocato il metodo Write con una qualsiasi istanza di Log, esegui la seguente Action". Il delegate passato come Action al metodo Do esegue la solita logica del mock manuale usato da Antonio. Per il resto il codice di test è sostanzialmente identico. La logica del terzo metodo di test è la solita quindi vi posto solo il codice:

   1:  public void Two_Logs_Enqueued_Are_Served_One_At_Time()

   2:  {

   3:      var writer = MockRepository.GenerateMock<ILogWriter>();

   4:      var thread = new LogThread(writer);

   5:      int writerCallCount = 0;

   6:      var resetEvent = new ManualResetEvent(false);

7:

   8:      writer.Expect(x => x.Write((Arg<Log>.Is.Anything))).Do(new Action<Log>(l =>

   9:      {

  10:          writerCallCount++;

  11:          resetEvent.WaitOne();

  12:          writerCallCount--;

  13:      }));

14:

  15:      Log log1 = new Log();

  16:      thread.Enqueue(log1);

  17:      while (writerCallCount < 1)

  18:      {

  19:          Thread.Sleep(0);

  20:      }

21:

  22:      Log log2 = new Log();

  23:      thread.Enqueue(log2);

  24:      while (thread.RunningThreadCount < 2)

  25:      {

  26:          Thread.Sleep(0);

  27:      }

28:

  29:      Assert.AreEqual(1, writerCallCount);

30:

  31:      resetEvent.Set();

  32:      while (writerCallCount > 0)

  33:      {

  34:          Thread.Sleep(0);

  35:      }

  36:  }

In fine passiamo all'ultimo metodo di test:

   1:  public void When_The_Writer_Throws_An_Exception_The_QueueLength_Is_Decreased()

   2:  {

   3:      var writer = MockRepository.GenerateMock<ILogWriter>();

   4:      var thread = new LogThread(writer);

   5:      bool isWriting = false;

6:

   7:      writer.Expect(x => x.Write((Arg<Log>.Is.Anything))).Do(new Action<Log>(l =>

   8:      {

   9:          isWriting = true;

  10:          throw new Exception();

  11:      }));

12:

  13:      thread.Enqueue(new Log());

  14:      while (!isWriting)

  15:      {

  16:          Thread.Sleep(0);

  17:      }

  18:      while (thread.RunningThreadCount > 0)

  19:      {

  20:          Thread.Sleep(0);

  21:      }

  22:      Assert.AreEqual(0, thread.RunningThreadCount);

  23:  }

Anche qui la parte interessante è la configurazione del mock object, in questo test la sintassi del mock rimane uguale ai test precedenti, quello che cambia è la logica contenute nell' Action delegate passato al metodo Do, il quale scatena un' eccezione.

Nel mio repository personale ho creato tre proggeti uno con la versione manuale dei mocks, uno che usa RhinoMocks ed in fine uno che usa Moq, il tutto è reperibile a questo url: http://makesimple.googlecode.com/svn/trunk/UnitTestMultithreading

Technorati Tag: Multithreading,Mocks,UnitTest,TDD

Mixin, POCO e INotifyPropertyChanged mito o realtà?

Matteo Baglini — Wed, 06 Aug 2008 21:54:54 GMT

Dopo aver chiesto ad i CDays2008 a Mauro cosa pensava dei mixin, dopo aver letto i vari post di Andrea, Raffaele e Gian Maria che parlano di POCO e dopo aver letto i due post (qui e qui) nel blog inglese di Gian Maria ho deciso di spiegare meglio cosa intendevo con il mio commento al post di Andrea.

Gian Maria mostra due modi diversi per rivolvere il "problema" dell'interfaccia INotifyPropertyChanged creando proxy a run-time, io avevo risolto il solito problema usando Spring.NET AOP. Questo dimostra che come al solito ci sono svariati modi per ottenere il solito risultato.

Finita questa piccola anticipazione arrivo al nocciolo del discorso e sparo la mia sentenza...nessuna di queste implementazioni è usabile!! Vi chiederete perchè ed io sono qui per dimostrarvelo. Piccola demo, provate a creare una semplice BindingList<Customer>, aggiungete ad essa un numero imprecisato di Customer-proxaty, agganciate l'evento ListChanged ed in fine provate a modificare la proprietà di un Customer della BindingList...et vualà l'evento non viene scatenato, cosa che dovrebbe accadere se Customer implementasse normalmente INotifyPropertyChanged.

Quando per la prima volta mi sono trovato davanti a questo problema armato di Reflector sono andato a sbirciare il codice della classe BindingList<T> ed ho trovato l'inghippo. Guardando il codice mostrato nell'immagine vediamo che la seconda linea di codice verifica se il tipo INotifyPropertyChanged è assegnabile dal tipo Customer, questa verifica nel caso di Customer in versione POCO è assolutamente falsa dato che il tipo Customer non sa niente di INotifyPropertyChanged. Per confermare questa teoria mi sono creato un po di test unitari che riproducono il problema, vediamoli. In entrambi i casi di test la creazione del Customer è stata "nascosta" dentro dei metodi Factory dato che non mi interessa mostrarne l'implementazione in questo post. Per prima cosa ho creato due classi Customer la prima implementa INotifyPropertyChanged e la seconda no, però ha le properties marcate come virtual per permettere la creazione del proxy a run-time.

        1: public class Customer : INotifyPropertyChanged

       2: {

       3:     public event PropertyChangedEventHandler PropertyChanged;

       4:     private Guid id = Guid.NewGuid();

       5:     private string name;

       6:  

       7:     public Guid Id {

       8:         get { return id; }

       9:     }

      10:     public string Name {

      11:         get { return name; }

      12:         set {

      13:             if (name != value) {

      14:                 name = value;

      15:                 RaisePropertyChanged("Name");}

      16:             }

      17:     }

      18:     private void RaisePropertyChanged(string propertyName)

      19:     {

      20:         if (PropertyChanged != null)

      21:             PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

      22:     }

      23: }

       1: public class CustomerPoco

       2: {

       3:     private Guid id = Guid.NewGuid();

       4:  

       5:     public virtual Guid Id {

       6:         get { return id; }

       7:     }

       8:     public virtual string Name { get; set; }

       9: }

Dopodiché ho creato due metodi di test, uno verifica se il Customer è castabile a INotifyPropertyChanged mentre l'altro verifica se è assegnabile.

       1: [Fact]

       2: public void ShouldBeCompatibleWithTypeINotifyPropertyChanged()

       3: {

       4:     Customer customer = CustomerFactory.CreateCustomer();

       5:     (customer is INotifyPropertyChanged).ShouldBeTrue("Is not INotifyPropertyChanged");

       6: }

       7: [Fact]

       8: public void ShouldBeAssignableToTypeINotifyPropertyChanged()

       9: {

      10:     typeof(INotifyPropertyChanged).IsAssignableFrom(typeof(Customer))

      11:         .ShouldBeTrue("INotifyPropertyChanged is not assignable from Customer");

      12: }

In questo caso entrabi i test passano perfettamente, proseguiamo eseguendo i soliti test su CustomerPoco:

       1: [Fact]

       2: public void ShouldBeCompatibleWithTypeINotifyPropertyChanged()

       3: {

       4:     CustomerPoco customer = CustomerFactory.CreateCustomerPoco();

       5:     (customer is INotifyPropertyChanged).ShouldBeTrue("Is not INotifyPropertyChanged");

       6: }

       7: [Fact]

       8: public void ShouldBeAssignableToTypeINotifyPropertyChanged()

       9: {

      10:     typeof(INotifyPropertyChanged).IsAssignableFrom(typeof(CustomerPoco))

      11:         .ShouldBeTrue("INotifyPropertyChanged is not assignable from CustomerPoco");

      12: }

In quest'ultimo caso il primo test passa mentre il secondo no distruggendo i nostri sogni di sviluppatore lazy che non doveva più implementare INotifyPropertyChanged . Ecco perchè nel mio commento al post di Andrea ho detto: "...perchè il framework di per se non conosce i mixin quindi è stato scritto "bloccandone" l'uso". Problemi simili sono risolvibili con diversi hack, basta barare con un po di reflection dopo aver istanziato la collection:

       1: private static void EditRaiseItemChangedEvents(BindingList<Customer> list)

       2: {

       3:     FieldInfo _fi = list.GetType().GetField("raiseItemChangedEvents", BindingFlags.NonPublic | BindingFlags.Instance);

       4:     bool raiseItemChangedEvents = (bool)_fi.GetValue(list);

       5:     if (!raiseItemChangedEvents) _fi.SetValue(list, true);

       6: }

ed il gioco è fatto ma in generale hanno un costo troppo alto, sia di implementazione che di manutenzione dato che il problema non si presenta solo per collection come la BindingList ma anche per controlli come il BindingSource delle WindowsForm.

Technorati Tag: Mixin,AOP,INotifyPropertyChanged,POCO

Google C++ Testing Framework

Matteo Baglini — Wed, 16 Jul 2008 12:33:26 GMT

Nei miei projetti C# faccio un largo uso di test unitari, utilizzando NUnit o xUnit.NET, so già che entro la fine dell'anno prenderò in consegna una grande applicazione C++, quindi in passato avevo dato un'occhiata veloce a quello che era il framework di testing di riferimento: CppUnit .
Adesso Google ha rilasciato il proprio framework per fare testing automatico di codice C++, non l'ho ancora provato (...aaahhhh il tempo) ma sembra proprio ottimo!

Fonte: InfoQ: Announcing: New Google C++ Testing Framework