Value of unit testing property setters to check events [duplicate]

Question

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

Answer 1

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.

Answer 2

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.