Christopher Bennage : C#, TDD

Unit Testing Change Notification

Christopher Bennage — Thu, 13 Nov 2008 20:43:05 GMT

In WPF work, it is very common to work with implementations of INotifyPropertyChanged. We need support for change notification in order to bind to the UI, and this interface is frequently the best approach. This means I have lots of properties that look like this:

public string FirstName
{
    get { return _firstName;}
    set
    {
        _firstName = value;
        RaisePropertyChanged("FirstName");
    }
}

I've gone back and forth as to whether or not I should test these properties for change notification on properties. My main argument for not doing it, is the ROI. The typical test pattern might look something like this:

[Test]
public void FirstName_raises_change_notification()
{
    bool has_property_changed = false;
    _person.PropertyChanged += 
        (s, e) => { if (e.PropertyName == "FirstName") has_property_changed = true; };
    _person.FirstName = "new_name";

    Assert.That(has_property_changed);
}

Sure, this isn't a long test, but when you consider the number of properties I could be dealing with you'll see the potential for a lot of noise.

I also don't like the fact that I have yet another string in my code; easy to miss when refactoring. Nevertheless, I feel like I ought to have test coverage for these change notifications.

What's the solution? Make change notification easier to test.

Step One

I extracted out the test pattern into an extension method that applies to INotifyPropertyChanged. So my test now looks like this:

[Test]
public void FirstName_raises_change_notification()
{
    _person.AssertThatPropertyRaisesChangeNotification(
        () => _person.FirstName);
}

By using an expression to identify the property, I removed the magic string. I also have an overload if I need to set the property to a specific value:

[Test]
public void FirstName_raises_change_notification()
{
    _person.AssertThatPropertyRaisesChangeNotification(
        () => _person.FirstName, "new_name");
}

The code for the extension is this:

public static class AssertExtensions
{
    public static void AssertThatPropertyRaisesChangeNotification<T, K>(
        this T propertyOwner,
        Expression<Func<K>> property,
        K valueToSet) where T : INotifyPropertyChanged
    {
        var has_property_changed = false;

        var memberExpression = (MemberExpression) property.Body;
        var propertyInfo = (PropertyInfo) memberExpression.Member;

        propertyOwner.PropertyChanged +=
            (s, e) => { if (e.PropertyName == propertyInfo.Name) has_property_changed = true; };

        propertyInfo.SetValue(propertyOwner, valueToSet, null);

        if (has_property_changed) return;

        var msg =
            string.Format(
                "The property, {0}, did not raise change notification.\n" +
                "The property was set to '{1}'.\nThe property is owned by {2}",
                propertyInfo.Name,
                valueToSet,
                typeof (T).Name);

        throw new AssertionException(msg);
    }

    public static void AssertThatPropertyRaisesChangeNotification<T, K>(
        this T propertyOwner,
        Expression<Func<K>> property) where T : INotifyPropertyChanged
    {
        propertyOwner.AssertThatPropertyRaisesChangeNotification(property, default(K));
    }
}

Step Two

The next step (which I haven't done yet) would be to provide a fluent API for easily expressing which classes and properties I care about. With the extension above, I'm still just dealing with one property at a time.

What I would like is a way to say "all public properties on class X, except Y & Z" or perhaps "only properties Y & Z on class X". Then I can have concise, descriptive, intent-revealing tests regarding change notification.

Thoughts? Improvements?

Building a WPF Application: Part 3

Christopher Bennage — Wed, 20 Aug 2008 04:28:00 GMT

Table of Contents

Application Architecture

I'm going to back up and bit discuss my overall approach to structuring this WPF project. So far the solution consists of four projects:

ChumChase is the actual WPF project.
FriendFeed is the official .NET api I downloaded from here, and patched so that it would compile. :-)
IntegrationTests is for testing the bits of the application that interact with the FriendFeed api. I separated this out because it is much slower to run than my Specifications tests, and goes beyond the trust boundary of the app.
Specifications is the bulk of the unit tests for the project. I'm influenced by the whole BDD approach, and I like to think of my unit tests as executable technical specifications.

Project Structure

In the main project you'll find the following:

Presenters - This folder contains the presenter classes. I usually name these classes with the suffix "Presenter, though that's a bit of a hang over from other frameworks (MonoRail, RoR). This directory is where I have the HomePresenter class we've been discussing.
Views - These are usually user controls or some derivative thereof. I name them to correspond to their presenter. So you would expect, since we have HomePresenter, to find HomeView.xaml. (Actually, I goofed and the current source has the view named HomeFeedView.xaml).
Model - This is the object model that represents the "business problem" I'm trying to solve. In this case it happens to mirror the actual api quite a bit.
Repositories - Here I am influenced by Eric Evans' book on Domain-Driven Design. Repositories are classes that allow me to access/persist data in a way that makes sense to my business domain. It's also a place where I can hook in orthogonal concerns such as logging, caching, or security. Repositories differ from the traditional data access layer in that there is an emphasis on the domain model (as opposed to following the semantics of a relation database).
Services - These are supporting classes. They are not necessarily part of the business or problem domain. A classic example is an SMTP provider. Classes in your model or presenters might utilize these.
Framework - These support the framework of application, but don't have anything to do with the business concern. If we need to create a base class for views, we'd put it here. Currently, I have a class there that is going to assist us with binding to commands. This is code that could likely be pushed out to a reusable library.

Aside from these folders you will also find:

App.xaml - This is the starting point for the application. It will kick off our Windsor configuration, and launch the first window for the application. Eventually, we'll include some application-wide resources in the xaml, primarily for styling.
Shell.xaml - This is the main window of the application. I call it Shell, because there is very little to its UI. It's content is bound to view of our current presenter. This class might have some logic in it's code-behind if we need to do some things like managing a set of tabs. It also provides the overall layout of the application.
ApplicationController - I briefly mentioned this in the last post. Honestly, I've waffled a bit on what to call it. It's responsibility is to coordinate the presenters for the application. For example, if presenter X needs to load presenter Y it passes that request to the application controller. In this, it also handles some statefulness for the overall application. This will become more clear as we begin to work with the class.

What's Not Here Yet

There are several other things that usually appear in my projects. I often end up with a base class for test fixtures, though I think the new Rhino.Mocks features might affect that. However, the big piece that's missing is the folders and files related to organizing the XAML.

It's common for me to have the following:

Colors & Brushes - I typically have a resource dictionary dedicated to defining the colors and brushes used in the application.
Default Styles - When I provide a completely custom style for an application, I'll have a resource dictionary that defines all of the default styles for controls. It useful to note that I avoid putting control templates inline in this dictionary.
Control Templates folder - In this folder, I will have a file for each control template in the application. I'll usually have a "manifest" resource dictionary where I merge in all of the individual templates. This helps to keep the structure clean in other areas. These are the control templates that are referenced in my default styles dictionary.
Data Templates folder - Inside the Views directory, I will have a sub-folder for data templates. Data templates really are views.

What Happens at Runtime?

A synopsis of what happens at runtime, well, what will happen once we've finished:

App.xaml starts off.
In its constructor, we configure our container, which in this case is Windsor. The container is told how to resolve resources, such as where do I find the actual implementation of IFriendFeedProxy.
Still in the constructor, we then request an instance of IApplicationController, and call StartApplication(). Note that we don't set the StartupUri in the XAML for App.
StartApplication() might handle some things like loading up user preferences, but mostly it will initialize and open Shell.xaml.
Somewhere around here we'll request the HomePresenter from the container, and inject into the shell.
As the user interacts with the application, presenters may be removed and new ones injected (probably into a tab, or new window). The shell's code-behind has the code for actually placing these presenter's views into the layout.
The presenter will have use commands as properties that can be bound to in there views. These commands are coordinators of individual activities in the application.

I'm certain that parts of this are confusion, but I believe it will make sense as we continue to build the application. As always, your feedback is welcome.

More to come!

Continue to Part 4.

Building a WPF Application: Part 2

Christopher Bennage — Sun, 17 Aug 2008 01:34:00 GMT

Table of Contents

So let's get back to this whole building a WPF application thing.

A number of things went down since my last post: I was out sick with a stomach bug for few days, my infant son caught the same bug and subsequently we spent a few days in the hospital (he's fine now, it was nothing serious), and I finally caught up on the AAA syntax in Rhino.Mocks.

Changing My Testing Style

Lots of people have blogged about the AAA syntax here, here, and here (to list a few). I won't go in depth, but briefly the idea is that you arrange your unit test thusly:

Arrange: do the minimal setup required to execute the test
Act: execute the actual code under test
Assert: assert that the code did what you expected

I decided to adopt this style. It seems to yield more readable, more focused, and less brittle tests. I rewrote the test from my last post using AAA. The original test was this:

[TestFixture]
public class The_presenter_for_the_home_feed : TestFixtureBase
{
    private HomePresenter _presenter;
    private IFeedRepository _feedRepository;

    protected override void given_the_context_of()
    {
        _feedRepository = Mocks.StrictMock<IFeedRepository>();
        _presenter = new HomePresenter(_feedRepository);
    }

    [Test]
    public void can_refresh_the_home_feed()
    {
        using (Record)
        {
            Expect.Call(_feedRepository.FetchHomeFeed())
                .Return(new List<Entry>());
        }

        using (Playback)
        {
            _presenter.RefreshHomeFeed();
        }
    }
}

and I rewrote it as this:

[TestFixture]
public class The_presenter_for_the_home_feed : TestFixtureBase
{
    private HomePresenter _presenter;
    private IFeedRepository _feedRepository;

    protected override void given_the_context_of()
    {
        _feedRepository = MockRepository.GenerateStub<IFeedRepository>();
        _presenter = new HomePresenter(_feedRepository);
    }

    [Test]
    public void can_refresh_the_home_feed_when_credentials_are_available()
    {
        _presenter.RefreshHomeFeed();
        _feedRepository.AssertWasCalled(x => x.FetchHomeFeed());
    }
}

Again, you can gather more details about this approach in one of the links above.

One interesting note though is that AssertWasCalled is an extension method and we're using it to assert the method FetchHomeFeed() was actually called on feedRepository.

(I also think that I should not have used StrickMock in the original test, as that added to fragility of the test.)

I tend to think of my code in terms of sentences and paragraphs, at least when it comes to the use of white space. You'll notice as the tests get a little larger that there will usually be three "paragraphs" in the code: arrange, act, assert.

Focusing on the Story

I said in my last post that the core story for this application is to retrieve the home feed. As such, I'd like to take the shortest path to getting that feature fully functional. The next few steps are roughly:

Write a proxy to wrap the existing FriendFeed api, but just enough to fetch the home feed.
Write a repository that will manage the home feed data. Even though this seems superfluous at the moment, it's a seam in the application where I will add future functionality (such as caching, logging, etc.).
Provide support for authentication. The FriendFeed api requires a username and remote key for accessing the home feed.

Very soon, I want to be able to launch the application, click a Refresh button, and see my feed. If I haven't provided credentials, I want the application to prompt me for them.

The Credentials Problem

The parts of the story regarding credentials raise some interesting design questions. Let's consider some of the pieces of the puzzle.

The HomePresenter is going to initiate the act getting the home feed. We've already seen that HomePresenter is going to invoke some implementation of IFeedRepository. The repository will talk to the FriendFeed api through a wrapper (IFriendFeedProxy) . Inside the wrapper class is the official .NET FriendFeed client, and it is the class that is really interested in the credentials. It's what talks to the FriendFeed web service, and that needs to be authenticated with the credentials. So at the bottom of this, somewhere in our code, we'll have this:

FriendFeedClient client = new FriendFeedClient("username", "remoteKey");

I'm using the Dependency Inversion Principle (which I'll talk about more later). However a consequence of this is that the constructor for HomePresenter takes an IFeedRepository and an IApplicationController.

In turn, my implementation of IFeedRepository, cleverly named FeedRepository, requires an instance of IFriendProxy in its constructor. My implementation of IFriendProxy wraps the official api. Did you follow all of that?

When I first began working through the design, I thought that I'd have to request the credentials from the user at the presenter level, and then pass them down to the repository, then to the proxy which would in turn set them on the actual client. But I could tell quickly that this smelled bad. The repository doesn't need to be concerned with credentials, and neither the HomePresenter. So far there are really just two classes that need to know about credentials: some sort of UI for getting the credentials from the user (that is a presenter of some sort) and FriendFeedProxy.

Oh and what's this IApplicationController interface all about? Um, I'll come back to that in the next post.

Single Source

Ideally, what I want is a single source for the credentials: a class whose sole responsibility is managing the current set of credentials. This lead me to create an ICredentialsSource interface. In order to flesh out what the interface should look like I began writing tests for how the client proxy would interact with it:

[TestFixture]
public class The_client_for_FriendFeed
{
    private const string _username = "your_username";
    private const string _remotekey = "your_remotekey";
    private ICredentialsSource _credentials;
    private FriendFeedProxy _client;

    [SetUp]
    public void given_the_context_of()
    {
        _credentials = MockRepository.GenerateStub<ICredentialsSource>();
        _client = new FriendFeedProxy(_credentials);
    }

    [Test]
    public void can_get_the_home_feed_when_authenticated()
    {
        _credentials.Stub(x => x.UserName).Return(_username);
        _credentials.Stub(x => x.RemoteKey).Return(_remotekey);
        _credentials.Raise(x => x.CredentialsChanged += null, _credentials, EventArgs.Empty);

        var feed = _client.FetchHomeFeed();

        IList<Entry> entries = feed.ToList();
        Assert.That(entries[0].Id, Is.Not.Null);
        Assert.That(entries[0].Title, Is.Not.Null);
        Assert.That(entries[0].Published, Is.Not.Null);
    }

    [Test]
    [ExpectedException(typeof (WebException))]
    public void cannot_get_the_home_feed_when_not_authenticated()
    {
        var feed = _client.FetchHomeFeed();
    }

    [Test]
    public void updates_credentials_when_the_credentials_source_changes()
    {
        //arrange
        _credentials.Stub(x => x.UserName).Return(_username);
        _credentials.Stub(x => x.RemoteKey).Return(_remotekey);

        //act
        Assert.That(_client.DoesClientHaveCredentials, Is.False);
        _credentials.Raise(x => x.CredentialsChanged += null, _credentials, EventArgs.Empty);

        //assert
        Assert.That(_client.DoesClientHaveCredentials, Is.True);
    }
}

These tests live in my IntegrationTests assembly, separate from my "real" unit test is the Specifications assembly. I consider these tests to be integration tests because they actually interact with the web services. They are not run as often as my Specifications.

I found these tests hard to write, and I would appreciate any feedback on how to improve them.

My point here though is to illustrate how these tests led me to create ICredentialsSource. I know that there will be a little more to it, a method perhaps that will allow me to set the credentials, but we'll get to that when we need it.

Right now, the interface looks like this:

public interface ICredentialsSource
{
    string UserName { get; }
    string RemoteKey { get; }
    event EventHandler CredentialsChanged;
}

I obviously need the username and remote key (and I was tempted to create a class that represented them as a unit.) I also discovered that I wanted the credentials source to raise a change notification event so that the proxy client would be aware when the user changed them.

Some other places in the application will actually set the credentials on this source, perhaps a yet-unwritten presenter whose job will be to request them from the user. This really helps to decouple responsibilities and keep the code clean. For this approach to work however, our application will need a single instance of this class. I'll show how I'll handle that when we cover dependency injection.

I had a lot of interruptions trying to complete this post, and I had to go back reread what I've written so far. In doing so, I realized that I ought to take a step back and explain my overall default architecture that I'm using. That will be the subject of my next post; and I promise to get the actual WPF bits soon!

On to Part 3.

Building a WPF Application: Part 1

Christopher Bennage — Tue, 22 Jul 2008 23:51:00 GMT

Table of Contents

I actually meant to say in my last post that I had investigated the API options for FriendFeed and they have a C# wrapper already available here. It's packaged up in a single download with its Python and PHP counterparts. Unfortunately, it has compilation errors. I fixed the errors and then I let ReSharper (R#) have its way with it [R#: Ctrl+Alt+Shift+F]. Yes, I do understand that the Code Cleanup feature of R# can be a nuclear bomb of churn for diffing your source, but egads I do love it so.

I also broke out the FriendFeed classes into separate files [R#: F6].

Hmm, I just decided that I'll notate R# and VisualStudio keyboard shortcuts like this [app:shortcut]. Is there already a convention for that out there?

I also decided to keep the FriendFeed code in a separate assembly. I don't always advocate assembly proliferation, but it made sense in this case. I created a project called FriendFeed and moved all their classes there. I also preserved their namespace, FriendFeed, as well. (I'm getting tired of typing "FriendFeed".)

At this point, I just wanted to get a feel for the API. So I read over what appeared to be the significant classes, and I used a couple of tests to see how it really works. Simple enough, instantiate the client and call FetchHomeFeed().

Building in Seams

I picked up the term seam from Ayende in this post. You can think of a seam as a natural boundary in an application. It's a place where you easily extend or modify an application. It's a little bit like a Bounded Context, but just a little. I used to try to coerce my design into the metaphor of layers, but seams are a more natural concept. You might also think of them as a way of describing componentized architecture.

Consider the example of a desktop computer: you have a motherboard, CPU, memory, video card, etc. All of the components are required for the computer to function, but you can replace any one of them. You can extend the functionality of the computer by adding more hardware. Some things might be tightly coupled, like those wretched integrated video cards. But you don't think of these components as layers. This is a flexible way to architect your application.

Seams are a standard consideration for me when it comes to designing an application. Yes, you can go crazy with it, you can go crazy with anything. In the case of ChumChase, I don't want to be tightly coupled to the official API. I have a few reasons right now: [a] the official API might change. [b] I might want to implement my own API against their web services just for kicks [c] it's a good excuse to demonstrate the technique. I'm going to hide the FriendFeed API behind a repository. The IFeedRepository interface will be a seam in my application.

MVP

I mentioned before that I'm going to use Model-View-Presenter. This pattern is similar to MVC, and like barbeque sauce, everyone has their own flavor. In my case, a presenter is a class that represents the behavior of the UI, and possibly some state. It is ignorant of how the UI visually appears. The view will be a user control, window, page, tab item, etc. We'll use data binding to glue the two together. The ignorance of the presenter about the view is important because it helps us to isolate the presenter in our unit tests.

TDD

It's ~~sometimes~~ hard to decide where to start writing to tests. I tend to write tests that reflect the behaviors of the user interacting with the application. This is as opposed to testing how the application might interact with a data source, or some other more internal function of the application. This approach of working from the outside in helps prevent me from making too many assumptions about the internals. The negative is that I have to provide mocks or stubs for the dependencies that I haven't written yet.

My core story, that is the basic behavior that I'm interested in, is for the application to fetch my home feed. I'll place this feature on a class called HomePresenter. HomePresenter might end up being my only presenter, I don't know yet. It common though for applications to have several presenters. We'll talk later about how to logically organize presenters.

Let's look at a test:

[TestFixture]
public class The_presenter_for_the_home_feed : TestFixtureBase
{
    private HomePresenter _presenter;
    private IFeedRepository _feedRepository;

    protected override void given_the_context_of()
    {
        _feedRepository = Mocks.StrictMock<IFeedRepository>();
        _presenter = new HomePresenter(_feedRepository);
    }

    [Test]
    public void can_refresh_the_home_feed()
    {
        using (Record)
        {
            Expect.Call(_feedRepository.FetchHomeFeed())
                .Return(new List<Entry>());
        }

        using (Playback)
        {
            _presenter.RefreshHomeFeed();
        }
    }
}

First, my TestFixtureBase is just an abstract class to reduce clutter. The Mocks, Record, and Playback properties all exist on it and they are really just pass-throughs to Rhino.Mocks. Likewise, I have a setup method in TestFixtureBase that calls given_the_context_of() before each test is executed. It's meant to reset the system-under-test (SUT) into a consistent and pristine state.

Notice that I named my class and method such that they read as a specification for the behavior I'm testing: The presenter for the home feed can refresh the home feed. I'm not sure that I like saying "presenter" in the specification. If I was working with non-technical users, that wouldn't make sense to them. I could replace it with "UI" or "interface" or "screen" perhaps.

The test has two blocks or phases: record and playback. This is generally a big stumbling block for people. I know when I first encountered it I was thoroughly confused. The record phase is where I tell the test what I'm expecting to happen during the playback phase. The record phase plays the same roles as asserts.

The function we are really testing here is:

_presenter.RefreshHomeFeed();

Since there is not a state that I can verify after calling RefreshHomeFeed(), I am checking to make sure that it's doing what I expect it to do. That is, I expect it to get a list of entries from a repository of feeds.

The Expect.Call().Return() is Rhino.Mocks syntax that allows me to say: I expect my SUT to execute _feedRepository.FetchHomeFeed() and I expect that to return a List<Entry> instance. Right now Entry is just an empty class, but conceptually it represents a single item in the feed. You should also note that the relationship between my presenter and the repository is established in given_the_context_of().

Yes, this is a simple test, but writing this test helped me to shake out what I needed. Unfortunately, the test as it stands here does not reflect the process of writing it. I wrote some things, decided they didn't look right, changed them a bit and so on. It probably took me 10 minutes or so before I settled on what you see.

Moving on to the next test. This is in the same class, so you can read it as: The presenter for the home feed notifies the UI when the home feed is refreshed.

[Test]
public void notifies_the_UI_when_the_home_feed_is_refreshed()
{
    var property_has_changed = false;

    _presenter.PropertyChanged +=
        (s, e) => { property_has_changed = (e.PropertyName == "HomeFeed"); };

    _presenter.RefreshHomeFeed();

    Assert.That(property_has_changed);
}

I want to verify that when I call _presenter.RefreshHomeFeed() a change notification is raised for the HomeFeed property. This means my presenter needs a HomeFeed property. I have a boolean flag that helps me track the state and I'm using an inline delegate to set my flag when the property is changed. (There's actually a flaw in this test that we'll examine later, can you see it?)

I don't like strings though. If I happen to change the name of the HomeFeed property and forget to change the string in the test, I've broken my test. Of course, I'll notice as soon as I run the tests, but it would sure be nice to eliminate the string. So I wrote this extension method for PropertyChangedEventArgs:

public static bool HasChanged<T>(this PropertyChangedEventArgs args, Expression<Func<T>> property)
{
    var expression = (MemberExpression)property.Body;
    return expression.Member.Name == args.PropertyName;
}

Now I can change my test to the following and eliminate the string:

[Test]
public void notifies_the_UI_when_the_home_feed_is_refreshed()
{
    var property_has_changed = false;

    _presenter.PropertyChanged +=
        (s, e) => { property_has_changed = e.HasChanged(() => _presenter.HomeFeed); };

    _presenter.RefreshHomeFeed();

    Assert.That(property_has_changed);
}

Of course, in between these tests I was writing code to make them pass. (Red -> Green -> Refactor, right?) Here's what my presenter class looked liked afterwards:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq.Expressions;
using ChumChase.Extensions;

namespace ChumChase.Presenters
{
    public class HomePresenter : INotifyPropertyChanged
    {
        private readonly IFeedRepository _feedRepository;
        private IList<Entry> _homeFeed;

        public HomePresenter(IFeedRepository feedRepository)
        {
            _feedRepository = feedRepository;
        }

        public IList<Entry> HomeFeed
        {
            get { return _homeFeed; }
            private set
            {
                _homeFeed = value;
                OnPropertyChanged( ()=> HomeFeed);
            }
        }

        public void RefreshHomeFeed()
        {
            HomeFeed = _feedRepository.FetchHomeFeed();
        }

        public event PropertyChangedEventHandler PropertyChanged;

        private void OnPropertyChanged<T>(Expression<Func<T>> property)
        {
            if (PropertyChanged != null) PropertyChanged(this, property.CreateChangeEventArgs());
        }
    }
}

The source is now available here. ~~More to come!~~

Continue to Part 2.

Christopher Bennage : C#, TDD

Unit Testing Change Notification

Step One

Step Two

Building a WPF Application: Part 3

Application Architecture

Project Structure

What's Not Here Yet

What Happens at Runtime?

Building a WPF Application: Part 2

Changing My Testing Style

Focusing on the Story

The Credentials Problem

Single Source

Next

Building a WPF Application: Part 1

Building in Seams

MVP

TDD