Valore dell'unità che controlla i setter delle proprietà per controllare gli eventi [duplicati]

2

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"));
    
posta Matt Thrower 11.03.2015 - 17:52
fonte

2 risposte

3

In questo caso direi DEFINITAMENTE. Stai compiendo un'azione in una proprietà che è al di sopra e al di là di un semplice set di valori. I test unitari non solo convalidano il tuo design, ma lo dichiareranno come intenzione per i futuri sviluppatori che arrivano e pensano a rimuovere il tuo codice aggiuntivo.

    
risposta data 11.03.2015 - 18:07
fonte
3

In generale, non testare metodi banali senza logica. Una volta che il tuo getter o setter contiene la logica, allora puoi applicare un test unitario. La logica può essere qualsiasi cosa, dalla convalida dell'input a un'implementazione completa di qualcosa.

    
risposta data 11.03.2015 - 17:59
fonte

Leggi altre domande sui tag