Quando si codifica in WPF con il pattern MVVM, è comune vedere un sacco di istruzioni get / set di proprietà che generano un evento, che possono essere rilevate dal livello dell'interfaccia utente.
public string Address
{
get
{
return _address;
}
set
{
_address = value;
OnPropertyChanged("Address");
}
}
Molte classi contengono decine di questi. Il livello del codice boilerplate richiesto è visto come un male necessario dai sostenitori di MVVM.
Tuttavia, uno dei vantaggi chiave di MVVM rispetto ai tradizionali modelli code-behind è che è molto più facile eseguire il test dell'unità. Questo va bene per funzioni e cose simili, ma c'è un sacco di codice scoperto a causa del recupero e dell'impostazione di queste proprietà che viene spesso eseguito dal livello dell'interfaccia utente.
Mi ha fatto riflettere sul valore dell'unità che li ha testati. C'è una cosa preziosa da verificare qui: se una proprietà non aumenta l'evento previsto, può avere gravi ripercussioni sulla funzionalità dell'applicazione. D'altra parte, le modifiche a queste proprietà sono rare e il test delle unità comporterebbe un codice ancora più generico che dovrebbe essere mantenuto.
Le funzioni banali come questa meritano il sovraccarico aggiuntivo di scrittura e manutenzione dei test?
EDIT: un commentatore ha chiesto in che modo testare l'unità. Ecco un esempio di un'altra proprietà che ho provato perché il setter fa molto di più di un semplice evento:
Mock<IReciprocateRepository> repMock = GetMockRepository();
CampaignViewModel cVm = new CampaignViewModel(repMock.Object);
List<string> receivedEvents = new List<string>();
cVm.PropertyChanged += (sender, e) => receivedEvents.Add(e.PropertyName);
cVm.LoadHistory();
Assert.IsTrue(receivedEvents.Contains("MemberItems"));