Should I Test a Property’s Getter and Setter?

In this lesson

  • Implement INotifyPropertyChanged
  • Setup test to capture event dispatches



One of the main criticism of test driven development, or trying to get 100% test coverage, is that you start testing for things that may not have much value. For example, you might want to test whether or not a property getter and setter is working correctly. There’s really not much value in doing this, in that a lot of times code templates can make this very easy to implement. As well as with C#, if you’re using shorthand property notation, a lot of the runtime takes care of any setting or retrieving of local fields.


However, with Xamarin.Forms it is extremely important that the setter of a property in a ViewModel dispatches a PropertyChanged event. Without this event, the Xamarin.Forms UI, or User Interface, won’t know that it needs to update itself. In this video, we’re going to look at how we can test for not only property changed events, but events in general.


One of the first things I need to do is update our UserAuthenticationViewModel to implement the interface of INotifyPropertyChanged. This is the event that Xamarin.Forms UIElements listen to to update themselves. I’m going to add a default handler here just in case nothing’s listening to it, I don’t blow a runtime error when I dispatch this.


Once I have that, the next thing we need to do is go into our test and make sure that we write a test that looks for this PropertyChanged event. I’m going to say public void TestPropertySetters_DispatchedPropertyChangedEvent. Here again, we’re going to instantiate our ViewModel. I’m going to create a string that says PropNameThatChanged- or nameOfPropThatChanged. We’re going to set this to empty string. Then, we’re going to add an event handler, PropertyChanged. Let’s clean this up a little bit here. Then, we’re going to say Name of PropertyChanged = e. I’ve got to import PropertyChangedEvents, PropertyName, like so. Now, when we specify our email address we should be able to say NameOfPropThatChanged_ShouldEqual EmailAddress. If we run this, it should work. Oops, we forgot our test attribute. Now, when we run this, we should get a fail because we always want our test code to fail first.


So let’s make this work. We’re going to go into our property. I’m going to create a  private reference to this variable. I’m going to return emailAddress. We’re going to say emailAddress = value. Then we’re going to say PropertyChanged. This is the sender. We’re going to say new PropertyChangedEventArgs, then we’re going to say EmailAddress. Now, when we run our test, we get a green check mark which makes us very happy.


One of the reasons this is doubly critical in this particular case is that we want to make sure whenever email address changes, we also dispatch a change event for EmailIsValid. Because EmailIsValid is based on the value of EmailAddress. I’m going to add another check here. I’m going to say EmailIsValid.


Now when we run this, we’re still going to get a failure because we’re always overwriting the last name of the property. We should probably change this to a list. I’m going to change- I’m going to say List String PropsThatChanged = new List. We’re going to just push property. Now, we can say ShouldContain. And voila! We now have passing tests and we are able to check for more than one property changed at a time.


As you can see, sometimes even testing that a property changed event has been fired in the setter has a lot of value and is somewhat critical to our Xamarin.Forms applications.