2

This question already has an answer here:

When coding in WPF with the MVVM pattern, it's common to see a lot of property get/set statements that raise an event, which can then be picked up by the UI layer.

    public string Address
    {
        get
        {
            return _address;
        }
        set
        {
            _address = value;
            OnPropertyChanged("Address");
        }
    }

Many classes contain tens of these. The level of boilerplate code required is seen as a necessary evil by MVVM advocates.

However, one of the key advantages of MVVM over traditional code-behind models is that it's much easier to unit test. This is fine for functions and such, but there's a lot of uncovered code due to the getting and setting of these properties which is often done from the UI layer.

It made me wonder about the value of unit testing them. There's a valuable thing to check here: if a property doesn't raise the expected event, it can have severe repercussions for the functionality of the application. But on the other hand, changes to these properties are rare, and unit testing them would result in even more boilerplate code which would need to be maintained.

Are trivial functions like this worth the additional overhead of writing and maintaining tests?

EDIT: A commenter asked about how you'd unit test this. Here's an example from another property that I tested because the setter does more than just raise an event:

        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"));

marked as duplicate by gnat, Community Mar 12 '15 at 9:13

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Personal experience: I spend the better part of a day tracking down a faulty PropertyChanged event, due to a misspelling in the magic string. All properties that raise PropertyChanged now get tested. When in doubt, write the test. – CurtisHx Mar 11 '15 at 17:02
  • @CurtisHx: What do you assert against if the PropertyChanged call doesn't return anything, like the example above? Isn't it really more like an integration test at that point? – Robert Harvey Mar 11 '15 at 17:03
  • @RobertHarvey You can check whether the expected event has been received. See stackoverflow.com/questions/248989/… – Matt Thrower Mar 11 '15 at 17:05
  • @RobertHarvey I use a lambda for the event handler on my class under test, and store PropertyName from the PropertyChangedEventArgs in a local variable. The assert compares the property name that is expected to the property name that got passed. – CurtisHx Mar 11 '15 at 17:08
  • 1
    The beauty of experience. Things go wrong, you figure-out ways to avoid them. Couldn't care less what anyone thinks should or shouldn't be tested. If something is breaking the code, you find a way to prevent it if you feel it could keep happening. – JeffO Mar 11 '15 at 18:55
3

In this case I would say DEFINITELY. You are taking an action in a property that is above and beyond a simple value set. Unit tests will not only validate your design they will declare this as intent to future developers that come along and think about removing your additional code.

3

In general, don't test trivial methods containing no logic. Once your getter or setter contains logic, then you can apply a unit test. Logic can be anything from an input validation to a full blown implementation of something.

Not the answer you're looking for? Browse other questions tagged or ask your own question.