Christopher Bennage : TDD

Improving Asynchronous Tests for Silverlight

Christopher Bennage — Mon, 17 Jan 2011 16:29:00 GMT

First a confession, and I know I’ll invoke shame for this one: I have done Very Little Testing with Silverlight. I won’t bore you with reasons or excuses, but I wasn’t up on the state of unit testing in Silverlight until very recently. (In fact, I might still be missing some chunks.)

The Problem

Last week, I started writing some tests for Raven DB. I won’t call them ‘unit’ tests because they were really ‘integration’ tests. Specifically, I wanted to test the budding Silverlight client for Raven. This mean that my tests had to make calls to the Raven server, wait for the result, then assert something.

Large portions of the Silverlight client are cross-compiled and I wanted to do the same with the relevant tests. On the .NET side, a demonstrative test looks like this:

[Fact]
public void Can_insert_async_and_get_sync()
{
    using (var server = GetNewServer(port, path))
    {
        var documentStore = new DocumentStore { Url = "http://localhost:" + port };
        documentStore.Initialize();

        var entity = new Company { Name = "Async Company" };
        using (var session = documentStore.OpenAsyncSession())
        {
            session.Store(entity);
            session.SaveChangesAsync().Wait();
        }

        using (var session = documentStore.OpenSession())
        {
            var company = session.Load<Company>(entity.Id); // the SL client won’t have sync methods!

            Assert.Equal("Async Company", company.Name);
        }
    }
}

The client is making use of Task from System.Threading.Tasks, and in case you didn’t know, this namespace has been ported to Silverlight as part of the CTP for the new C# 5 async syntax.The idea here is to make the async code read synchronously.

Using XunitLight, I was able to cross compile a similar test and run it with the Silverlight Unit Test Framework. Only, it didn’t work.

It doesn’t work because the test is running on the UI thread, and the call to Wait() blocks the execution on the current thread while the Task returned from SaveChangesAsync() executes. This task is making use of WebRequest and deep in the bowels of Silverlight some calls are being marshaled back onto the UI thread. Only that thread is being blocked by Wait(), so nothing happens.

The Standard Solution

The Silverlight Unit Test Framework has some infrastructure for handling this sort of problem. Jeff Wilcox, who built the framework, talks about asynchronous test support in this post. Using the standard approach, I ended up with this test:

[Asynchronous]
[TestMethod]
public void Can_insert_async_and_load_async()
{
    var documentStore = new DocumentStore { Url = "http://localhost:" + port };
    documentStore.Initialize();

    var entity = new Company { Name = "Async Company #1" };
    using (var session_for_storing = documentStore.OpenAsyncSession())
    {
        session_for_storing.Store(entity);
        var result = session_for_storing.SaveChangesAsync();
        EnqueueConditional(() => result.IsCompleted || result.IsFaulted);
    }

    EnqueueCallback(() =>
    {
        using (var session_for_loading = documentStore.OpenAsyncSession())
        {
            var task = session_for_loading.LoadAsync<Company>(entity.Id);
            EnqueueConditional(() => task.IsCompleted || task.IsFaulted);
            EnqueueCallback(() => 
            {
                Assert.Equal(entity.Name, task.Result.Name);
                EnqueueTestComplete();
            });
        }
    });
}

The Asynchronous attribute tells the framework to use a queuing mechanism to execute the test. Then in your test, you must carefully arrange the code with various enqueue methods. This was actually one of the simpler tests, a couple of them had even more nesting of EnqueueCallback. It was functional, but my heart hurt.

I should also note that the code you see here is a mix of several things. From the Silverlight Unit Test Framework itself we have [Asynchronous] and the enqueue methods. (These methods are provided on a base class SilverlightTest). In addition, [TestMethod] is part of the Visual Studio Team Test (VSTT). In my .NET example above, I was using [Fact] from XUnit. The Silverlight Unit Test Framework includes a default provider for VSTT. Finally, the Assert.Equal call is from XUnit (well, from XunitLight).

The Alternative Solution

Writing the tests like this was killing me. So I lifted the syntax used in Caliburn for coroutines and I was able to convert the test to this:

[Asynchronous]
[TestMethod]
public IEnumerable<Task> Can_insert_async_and_load_async()
{
    var documentStore = new DocumentStore { Url = "http://localhost:" + port };
    documentStore.Initialize();

    var entity = new Company {Name = "Async Company #1"};
    using (var session_for_storing = documentStore.OpenAsyncSession(dbname))
    {
        session_for_storing.Store(entity);
        yield return session_for_storing.SaveChangesAsync();
    }

    using (var session_for_loading = documentStore.OpenAsyncSession(dbname))
    {
        var task = session_for_loading.LoadAsync<Company>(entity.Id);
        yield return task;

        Assert.Equal(entity.Name, task.Result.Name);
    }
}

How This Works

I’m leveraging the fact that all of the asynchronous work is performed with Task. In Caliburn, we use IResult for the same purpose. You’ll note that my test returns an IEnumerable of Task. I took the default implementation of the provider for VSTT, and I found the bit where the test was actually invoked and I changed it to this (note that methodInfo contains the test method):

public virtual void Invoke(object instance)
{
    var type = typeof (IEnumerable<>).MakeGenericType(new[] {typeof(Task)});
    if(type.IsAssignableFrom(methodInfo.ReturnType))
    {
        var executor = instance.GetType().GetMethod("ExecuteTest");
        executor.Invoke(instance, new[] {methodInfo});
    } else
    {
        methodInfo.Invoke(instance, None); // this is the original implementation
    }
}

I check to see if my test method returns an IEnumerable<T> and if it does, I then look for a method named ExecuteTest on my test class and I invoke that passing in my actual test method as a parameter.

public void ExecuteTest(MethodInfo test)
{
    var tasks = (IEnumerable<Task>)test.Invoke(this, new object[] { });
    IEnumerator<Task> enumerator = tasks.GetEnumerator();
    ExecuteTestStep(enumerator);
}

Yes, this code is far from bullet proof. It should check to make sure our test class contains an ExecuteTest method (among other things).

Finally, ExecuteTestStep takes each of the Task instances that are yielded and calls the various enqueue methods from SilverlightTest.

private void ExecuteTestStep(IEnumerator<Task> enumerator)
{
    bool moveNextSucceeded = false;
    try
    {
        moveNextSucceeded = enumerator.MoveNext();
    }
    catch (Exception ex)
    {
        EnqueueTestComplete();
        return;
    }

    if (moveNextSucceeded)
    {
        try
        {
            Task next = enumerator.Current;
            EnqueueConditional(() => next.IsCompleted || next.IsFaulted);
            EnqueueCallback(() => ExecuteTestStep(enumerator));
        }
        catch (Exception ex)
        {
            EnqueueTestComplete();
            return;
        }
    }
    else EnqueueTestComplete();
}

If you are familiar with the source from Caliburn Micro, you’ll notice that this is very similar to the logic for executing IResult instances.

The complete source, along with a few examples tests, is available on github.

I’ll likely improve it during the next couple of weeks. For example, there’s no real needs for the attributes when the method returns IEnumerable<Task>.

Feedback is welcome.

Testing Bindings In WPF

Christopher Bennage — Fri, 20 Feb 2009 03:56:00 GMT

I was inspired to get off my duff and blog today by a tweet from Scott Hanselman. I didn’t really dig into the context of his tweet, but it was about TDD and WPF. In case you haven’t figured it out, I’m a big fan of WPF and TDD. Luckily, I’ve had the opportunity to work on a number of varied WPF projects (most using TDD) over the last couple of years. One problem I experienced over and over was incorrect bindings in my Xaml (as I alluded to in this post). Binding errors are silent. They sneak up on you ninja-like. If you are keeping an eye on your Output window you can catch them, but it is very easy for them to just slip by.

About two years ago, Rob and I were working on a student records application for the FSU College of Music. The system handled the entire lifecycle of a student, from application to graduation, and that involved lots of data. We had a number of screens in the app that were merely large data entry screens. Binding errors where a problem, and it seemed like a new batch showed up every time we made a release to the users.

The errors might have been the result of renaming a bound property, bad spelling, or some other such silliness. They were easy mistakes to make and thus I began to think that we really needed a way to automatically test them.

Well, I’m lazy and time passed (maybe a year) and then I mentioned it again to Rob. The next day he committed a prototype to the Caliburn trunk. (He’s like my own personal Ayende.)

Here’s an example test copied directly from Caliburn’s documentation:

public class TestBase
{
    static TestBase()
    {
        var app = new MyApplication();
        app.InitializeComponent();
    }
}

[TestFixture]
public class TestCase : TestBase
{
    [Test]
    public void Test()
    {
        var validator = Validator.For<MyUserControl, MyModel>();
        var result = validator.Validate();

        Assert.That(result.HasErrors, Is.False, result.ErrorSummary);
    }
}

In TestBase, we initialize the actual application so that we have access to application level resources. We need to this in a static constructor because we don’t want more than one instance of the application in the AppDomain.

Now, check out the Test() method. The static class Validator.For<T,K>() method returns an instance of BindingValidator<K>. The type T is some FrameworkElement that contains the bindings we’re interested in and K is the type that the FrameworkElement is bound to. Calling the Validate() method causes Caliburn to instantiate T, crawl it’s tree, and collect all the bindings. It then compares those bindings to the type K to see if they are valid. Validate() actually returns an instance of ValidationResult<K>, which is a summary of everything that Caliburn found while comparing the bindings against the actual type T.

The assertion in the test means that we expect Caliburn to find no errors, and if it does to provide us the summary. This is useful because there might be a number of binding errors and the ErrorSummary will give us the whole list.

At this point, I’m just repeat what’s stated in Caliburn’s documentation. NH Prof was the first project where we’ve actually used the Testability features of Caliburn. Let’s check out a real live test from it:

[TestFixture]
public class MessageBoxViewTextFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<MessagePresenter> bindings;

    public MessageBoxViewTextFixture()
    {
        bindings = Validator.For<MessageBoxView, MessagePresenter>()
            .Validate();
    }

    [Test]
    public void BindingsDoNotHaveErrors()
    {
        Assert.That(bindings.HasErrors, Is.False, bindings.ErrorSummary);
    }

    [Test]
    public void MessageIsBound()
    {
        Assert.That(bindings.WasBoundTo(x => x.Message));
    }
}

This test is for the view that displays a simple popup message. We have a simple presenter that backs the view and it has a message to display in its property Message. It’s tested independent of the view. (This is nice because we have a case in NH Prof where a single presenter might be bound to multiple views.)

The ViewTestFixtureBase is identical to TestBase from the example above. Since it’s expensive to have Caliburn instantiate and crawl the UI validating the bindings, we only want to do this once. (I’m not really sure why I used the constructor, instead of [TestFixtureSetUp], but I did.)

The first test covers 90% of what you typically need, catching spelling errors, etc. The second test however explicitly checks to see if we are bound to the Message property on the presenter. This is useful because that’s the core reason for this view. There may be other properties bound, but this is the one we definitely care about. (I think this affords liberty to designers while ensuring that a view delivers the business value that was intended.)

Now, let’s pretend that I have a bad binding in my markup. Here’s the core snippet for the view used in the test above, MessageBoxView:

<Grid MaxWidth="260">
    <StackPanel>
        <TextBlock Foreground="{StaticResource Text}" 
                   FontSize="14"
                   TextWrapping="Wrap"
                   Text="{Binding Messyage}" />
        <Button Content="OK"
                Margin="4 8 4 4"
                HorizontalAlignment="Center"
                IsCancel="True" />
    </StackPanel>    
</Grid>

Oops, I misspelled Message in the binding! When I execute my tests, they both fail. The first because there is a binding error and the second because it can’t find Message. Here’s the actual exception from the first test:

NUnit.Framework.AssertionException: [MessageBoxView.Grid.StackPanel.TextBlock] The property 'Messyage' was not found on 'MessagePresenter'.
Expected: False
But was: True

Notice that it actually gives you the path to the offending binding: MessageBoxView.Grid.StackPanel.TextBlock. Now that’s just cool! Thanks Rob!

I can’t explain how much pain it saves to be able to do this. If you are doing TDD with WPF, you really need to check this out.

I’ll post over the weekend some tests that are a bit more BDD in their styles.

UI Patterns for WPF

Christopher Bennage — Tue, 20 Jan 2009 03:19:00 GMT

There’s a lot of recent buzz about the Model-View-ViewModel or MVVM. (I pronounce it like it rhymes with Auntie Em.) Rather timely for me as a lot of my thinking about implementing UI patterns in WPF has begun to coalesce.

There’s has been a lot of thought given to UI patterns prior to the advent of WPF. Martin Fowler has a relatively succinct historical overview of GUI architectures. I’d like to start here by discussing how these established patterns are mapped to WPF. After that, I’d like to explore how WPF allows us to improve on these patterns. We’re probably in for a series of posts here.

Why Patterns?

One guiding principle, both for testability’s sake as well as for myriad other reasons, is Separated Presentation. This is a just a special case of the general principle Separation of Concerns. We separate the concerns because they are easier to test, maintain, and extend.

Let’s assume that you buy into the value of testability. The next problem is that UI code is notoriously difficult to test. This is a product of the way UI frameworks generally work. The common solution is to push as much behavior as possible into Plain Old CLR Objects (POCO). In other words, if a class is tied to the UI framework, and thus is difficult to test, it should have as little logic in it as possible; instead that logic should be delegated to classes that are easier to test.

The Patterns

There are number of standard approaches, er, patterns, that have been recognized. My influences for interpreting these patterns are Martin Fowler, Jeremy Miller, John Gossman, and Dan Crevier.

I want to show you have these patterns look in code, so let’s establish a quick (and highly contrived) scenario. We have a registration form that accepts an email address, a password, and a confirmation of the password. There’s a button to initiate the registration, but the form has to be in a valid state in order for the button to be enabled. The rules are:

The email address cannot be blank.
The password cannot be blank.
The confirmation must match the password.

Now for the patterns…

The Autonomous View

This is what we don’t want to do, but usually do. All of the logic is in the code-behind. Very little is delegated out to other classes, and when it is, it is typically delegated to concrete types so that hard dependencies exist. It’s impossible to test with this pattern because it is impossible to isolate the behavior that need to be tested. Here’s the xaml and the code-behind.

Model-View-Presenter

I’ve used the term MVP a lot. (Hey, I am one now!) Fowler has suggested that MVP subsumes two more specific patterns (and that the term MVP should be retired in favor of them). Both of the child patterns have the same elements: a model, a view, and a presenter. Generally, the model is data that you are interested in, the view renders the data on screen, and the presenter handles all the “presentation concerns”. What constitutes “presentation concerns” though is part of what distinguishes the two child patterns.

Supervising Controller

The first of the MVP patterns is the supervising controller, or supervising presenter. (The terms controller and presenter are somewhat ambiguous themselves and are frequently interchanged.) The presenter in the supervising presenter pattern has properties that interact with the view through data binding. Frequently, you’ll have simple event handlers (e.g., the click event for a button) that merely call methods on the presenter. (There is an alternative to the event handlers, but I’ll get to that later.)

This pattern is easy to test because the presenter has most of the behavior for the UI and it is POCO. The deficit is that the view still contains some logic in the form of bindings.

Notice here that we’ve introduced bindings into the xaml and that there is almost nothing in the code-behind. The real behavior is here in the presenter.

Passive View

This flavor of MVP squeezes out the remaining behavior out of the view. With this pattern you define an interface for the view that the presenter operates against. The implementation of the view interface has to be very simple, you want the absolute bare minimum in the view. The view is passive because it doesn’t know or do anything. The presenter handles all of the logic and manipulates the view. In WPF, you’ll end up with more code in the code-behind (because you are implementing the interface), but you can avoid bindings. Why do you want to avoid bindings? Because they are harder to tests… or are they? More on that later.

Here’s the view’s interface. Note that the code-behind is more involved, but the xaml no longer has bindings. Also, notice how the presenter has to know a lot more about the view.

A Warning

We all want patterns to be distinct and specific, but the reality is that they are blurry. Often you will be combining elements from various patterns in order to accomplish what you need to do. Don’t get hung up on implementing a pure pattern.

Presentation Model vs MVVM

Actually, I will pick up here next time. I need to give you a reason to come back, right? :-)

If you are interested in the playing with the code examples, I’m posting it on CodePlex.

Building a WPF Application: Part 6

Christopher Bennage — Tue, 13 Jan 2009 05:29:21 GMT

ChumChase Table of Contents

I opened up the ChumChase code this evening with the sad realization that my last commits were on November 14th. Ouch. In reading over the code, something jumped out at me immediately. In the code-behind for Shell.xaml, I had a lot of logic that didn't need to be there. It was clumsy and not tested, but at least I had left myself a comment to that effect.

The code handled switching from the default view to the 3D view. If you don't know what I'm talking about, go back and read the older posts. The important part of Shell.xaml looked like this:

<Grid>
    <ContentControl x:Name="MainView" />

    <Button Content="Toggle View"
            VerticalAlignment="Top"
            HorizontalAlignment="Right"
            Click="ToggleView_Click" />
</Grid>

and the handler for the click (along with a dependent method) looked like this:

private void ToggleView_Click(object sender, RoutedEventArgs e)
{
    if (MainView.Content is DefaultFeedView)
    {
        SetView(new _2Don3DView());
    }
    else
    {
        SetView(new DefaultFeedView());
    }
}

private void SetView(IFeedView view)
{
    MainView.Content = view;
    view.RefreshButton.Click += Refresh_Click;
}

Yes, _2Don3DView is not a good name. I'll fix it. Aside from the appalling appellation, this code is not very WPF-ish. What is it doing anyway?

ContentControl is really a place holder. It represents the area in the application's shell where we want to stick the main content. In the handler, we check to see what is currently in the placeholder and we switch it out. Since each view had it's own button for refreshing the feed we needed to wire it up each time we switched the view. (Remember this way is naughty-naughty.) Our views implemented IFeedView so we could access their respective Refresh buttons.

A More Excellent Way

My ApplicationController class should really be responsible for this behavior. In order to make that happen, I created a property on it called CurrentPresenter. This property is the presenter that will back the current view. (A presenter is a class that contains the logic for a portion of the UI, the corresponding view is the visual part used to render that presenter.) Since the data context for Shell.xaml is already set to an instance of ApplicationController (it's named _controller in the code-behind), I was able to changed the markup to look like this:

<Grid>
    <ContentControl Content="{Binding CurrentPresenter}" />

    <Button Content="Toggle View"
            VerticalAlignment="Top"
            HorizontalAlignment="Right"
            Click="ToggleView_Click" />
</Grid>

and then the event handler to this:

private void ToggleView_Click(object sender, RoutedEventArgs e)
{
    _controller.ToggleView();
}

And now, let's examine the tests for the desired behavior. I wanted ToggleView to alternate between an instance of DefaultFeedPresenter and an instance of _2Don3DPresenter. (Bad Christopher, bad!) I did not want ToggleView to create new instances, but to reuse existing ones.

[TestFixture]
public class The_application_controller
{
    [SetUp]
    public void given_a_context_of()
    {
        // stuff omitted for brevity //
        _controller = new ApplicationController();
    }

    [Test]
    public void raises_change_notification()
    {
        _controller
            .AssertThatAllProperties()
            .RaiseChangeNotification();
    }

    [Test]
    public void uses_the_expected_presenter_by_default()
    {
        Assert.That(_controller.CurrentPresenter, Is.InstanceOfType(typeof(DefaultFeedPresenter)));
    }

    [Test]
    public void toggles_to_the_3D_view_when_the_default_is_current()
    {
        _controller.ToggleView();
        Assert.That(_controller.CurrentPresenter, Is.InstanceOfType(typeof(_2Don3DPresenter)));
    }

    [Test]
    public void toggles_to_the_default_when_the_3D_view_is_current()
    {
        var default_presenter = _controller.CurrentPresenter;
        _controller.CurrentPresenter = new _2Don3DPresenter(_controller);
        _controller.ToggleView();

        Assert.That(_controller.CurrentPresenter, Is.EqualTo(default_presenter));
    }
}

Ooo, hey, what's that first test? That raises notification bit? Oh, that just some cool stuff in Caliburn, you can read more about that here.

I added the following lines to ApplicationController in order to pass these tests:

private readonly IList<IPresenter> _presenters = new List<IPresenter>();
private IPresenter _currentPresenter;

public IPresenter CurrentPresenter
{
    get { return _currentPresenter; }
    set
    {
        _currentPresenter = value;
        RaisePropertyChanged("CurrentPresenter");
    }
}

public void ToggleView()
{
    CurrentPresenter = (CurrentPresenter is DefaultFeedPresenter)
        ? _presenters[1]
        : _presenters[0];
}

I initialized _presenters in the constructor for ApplicationController with the instances of the presenters. (I was tempted here to introduce an IoC container, but I didn't. We'll talk more about that later.)

So now, when ToggleView is called, the CurrentPresenter property is updated and change notification is raised, but what happens in the UI? How does it render the presenter instances? Well, given the markup from Shell.xaml we listed above, it doesn't do anything.

I Love DataTemplates So Much, Why Don't I Marry Them?

We need to tell WPF how to render each presenter. We already have user controls that define each view. We can reuse those. I added the following to the Grid containing my ContentControl:

<Grid.Resources>
    <DataTemplate DataType="{x:Type Model:DefaultFeedPresenter}">
        <Views:DefaultFeedView />
    </DataTemplate>
    <DataTemplate DataType="{x:Type Model:_2Don3DPresenter}">
        <Views:_2Don3DView />
    </DataTemplate>
</Grid.Resources>

The DataType property tells WPF that anything bound to an instance of the given type should use the template. Since I placed these in the resources for the grid, it will affect any bindings inside the grid. Each data template simply contains the corresponding user control. I could have inlined the user controls, but I already had tests in place and I believe this makes the markup easier to read.

In making these changes, I did break something. Something that was not being tested... but it's time for bed so I'll leave that for another night.

More to come!

TDD Firestarter in Tampa

Christopher Bennage — Wed, 07 Jan 2009 22:12:10 GMT

The new year has already gotten away from me and it's only 7 days old. (Come back, Baby Happy!)

In less than 2 weeks from now, we're going to a have full day of TDD in Tampa, FL. The event is designed so that everyone will find value, whether you are merely curious about methodology or a veteran practitioner.

We're starting off the day with introductory and intermediate session on TDD and following it up with some very focused sessions in the afternoon. (I'm going to be talking about doing TDD with WPF and I'll be using a little bit o' Caliburn as well.)

Saturday, January 17, 2009

9:00 AM–5:00PM

Click here to register or call (877) 673-8368 with event ID 1032397083.

Speakers include Cory Foy, Scott C. Reynolds, Sean Chambers, and Rob Eisenberg.

Please come out and join us! Did I mention it's free?

More information here...

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?

Solving Problems with TDD

Christopher Bennage — Thu, 06 Nov 2008 20:03:00 GMT

I'm giving a talk on TDD at our local UG tonight, and under the influence of some recent posts here on devlicio.us, I just finished reworking my presentation. This post is an outline for the first half of my presentation.

The Problems

Code has entropy. That is over time it deteriorates. At least, that's the metaphor we developers like to use. What is really means is that the code becomes harder to maintain and extend as it is maintained and extended over time. Did you follow that? Our typical approach to maintaining and extending code causes the code to become fragile and rigid and thus harder to maintain and extend in the future.

There are three common difficulties that arise, maybe more, but I'm focusing on three:

Unchangeable Code
Unintelligible Code
Unnecessary Code

A portion of code becomes unchangeable when its deeply entwined and entangled with other portions of code that have different responsibilities. You can't change method X because we really don't know what that will do to Y and Z.

Code can become unintelligible for lots of reasons: abbreviated names, circuitous logic, enormous methods, confusion of responsibilities, use of php☺, etc.

Finally, unnecessary code is code that is not used by the system. It can be vestigial, or as often happens, it can be the result of feature anticipation. We thought this was going to be needed in the app, so...

The Solutions

There are some generally accepted solutions to these three problems.

In the case of unchangeable code, we can apply such patterns as Separation of Concerns (SoC) and the Single Responsibility Principle (SRP). For addressing unintelligible code, we have a number of techniques such as thoughtful comments, explicit naming, SRP again, etc. Finally, for unnecessary code we have the old axiom of You Ain't Gonna Need It.

Okay, so we know how to solve the problems. Or least, we know how to mediate them. So what? What does that have to do with TDD?

My proposition is this: solutions are without value unless they are applied.

Additionally, when a problem occurs over time, the solution must be applied over time.

The Analogy

I just started going to the gym. It's been about a decade since I did that, but I'm back. For the past several years however, I have been preaching to certain family members the value of exercise and healthy diet. I knew the benefits: stress reduction, longevity, improved sleeping, and just plain feeling better. However, I wasn't really doing either.

I had the problem and I believed in the solution and, in fact, I made attempts to employ the solution. Ultimately, I was unsuccessful. That is, until I committed to go to the gym three days week at a set time and with a workout buddy.

My point is this, we are human beings and despite being smart we frequently revert to doing "the easiest thing". Therefore, we ought to set up some sort of framework of methodology or discipline where the easiest thing is actually what we want to do.

Additionally, I have to keep on going to gym. For as long as I want to be fit, I will need to exercise. In the same way, for as long as I want my code to fit I will need to apply good principles.

TDD as a Discipline

I will argue that TDD is a discipline that enables the application of the solutions outlined above. Perhaps you apply those solution naturally. Perhaps you can benchmark 200lbs because of your genetic disposition. Bully for you. Go ahead and skip the rest.

Let's examine a few essentials of TDD and see if they really address the problems we outlined.

Test First

I'm an advocate of automated testing in general. However, I do think that writing your tests first yields additional value. Primarily, it helps you discover your ideal API. In other words, you can design your API up front such that it is more intuitive. More intuitive means easier to understand.

Secondly, testing first helps you identify dependencies early. You quickly discover that class X will need a Y and so you are forced to create seams in the application at the onset. This encourages SoC and SRP.

Testing Units

It took me a long time to understand the "unit" part of unit testing. The idea is that you decompose your problem into units, and deal with the problem one unit at a time. You could call this "test just one thing". Okay, well what is "one thing"? That is hard to tell and comes with experience. Nevertheless, the practice of trying to decompose a problem and identifying units leads you back to SoC and SRP again.

Just Enough Code

Another tenet of TDD is to write only enough code to pass the test. Our natural instinct is to anticipate. It is part of what we are as developer, and it is not a bad thing. However, like many strengths, it can become a weakness. By constraining ourselves to a single problem at a time we will end up with less code. It also forces us to be conscious about our anticipation and to ask if a given scenario is really necessary.

Conclusion

I know that there is much contention over the actual value of TDD as a practice, and I am not going to force it on anyone (unless I hire you and now you are warned). However, I have found it to be a useful discipline for helping me to overcome common problems and because of that I encourage it's use.

Tricksy Dispatcher & Running Tests in TDD.NET

Christopher Bennage — Thu, 23 Oct 2008 15:42:00 GMT

Updated 11/07/2008

I recently ran into an interesting situation. I had an ObservableCollection bound to my UI in WPF, and I needed to updated this collection on something other than the UI thread. In other words, I was adding items to a UI-bound collection on a different thread, which triggered the change notification events on that non-UI thread. Unfortunately, you can't do that, the change notification events for ObservableCollection can only be execute on the UI thread.

Karl Hulme blogged about this and posted some custom collections he wrote to deal with the problem. Karl's solution was heavier (and more generic than I needed), so I distilled his code down to this:

public class BindableCollection<T> : ObservableCollection<T>
{
    private readonly Dispatcher _dispatcher;

    public BindableCollection(Dispatcher dispatcher)
    {
        if (dispatcher == null) throw new ArgumentNullException("dispatcher");

        _dispatcher = dispatcher;
    }

    protected override void OnPropertyChanged(PropertyChangedEventArgs e)
    {
        _dispatcher.Invoke(DispatcherPriority.Normal, (Action)(() => base.OnPropertyChanged(e)));
    }

    protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
    {
        _dispatcher.Invoke(DispatcherPriority.Normal, (Action)(() => base.OnCollectionChanged(e)));
    }
}

This really a simplified version of what Karl did, but it was all I needed. When you instantiate this collection, you pass in the dispatcher for the UI. You can easily get that using System.Windows.Threading.Dispatcher.CurrentDispatcher. In case you are not familiar with it, Dispatcher is WPF class for managing the queue of work items for a thread.

It's a sweet trick. To sum up, the collection is now dependent on a Dispatcher. We pass into it the Dispatcher for the UI thread. Then we override the change notification methods, so that we marshal the actual underlying change notification back onto the UI thread.

The cast to an Action looks a bit weird, but unfortunately lambdas are not implicitly cast to Actions.

The Unexpected Bug

I guess all bugs are unexpected, so whatever.

A few of our automated tests dealt with this new BindableCollection, and everything was green when I executed the tests through ReSharper's test runner. Likewise, everything ran as expected in the application itself. However, when running these test through TDD.NET the _dispatcher.Invoker call never returned.

Right now, it's important to give credit where it is due. Ayende solved this problem before I had time to fully grasp it even. If there is a Justice League of .NET, Ayende is Flash (and we think Justice Gray is probably Superman? I mean, the hair, right?).

Anyway, errors in this explanation are my own.

Diagnosis

When you call Invoke() the action is placed onto a queue. The processing of the queue is triggered by the method WndProcHook(). This method is the hook for processing message from the OS. In other words, the queue is only processed each time the window receives a message.

Now TDD.NET executes tests in a console, ReSharper's test execute in a GUI. So with TDD.NET, the queue is never processed and hence the Invoke method never returns.

The Revision

Ayende came up with the following revision to our collection. You can see some functional influence here:

public class BindableCollection<T> : ObservableCollection<T>
{
    private readonly Action<Action> _dispatcher;

    public BindableCollection(Action<Action> dispatcher)
    {
        if (dispatcher == null) throw new ArgumentNullException("dispatcher");

        _dispatcher = dispatcher;
    }

    protected override void OnPropertyChanged(PropertyChangedEventArgs e)
    {
        _dispatcher(() => base.OnPropertyChanged(e));
    }

    protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
    {
        _dispatcher(() => base.OnCollectionChanged(e));
    }
}

Instantiating this, might look like this:

new BindableCollection<stuff>(action => dispatcher.Invoke(DispatcherPriority.Normal, action));

However, in my tests, I can avoid the dispatcher altogether and simply:

new BindableCollection<stuff>(action => action());

Hope someone else finds this useful.

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.

Building a WPF Application: Part 0

Christopher Bennage — Mon, 21 Jul 2008 03:18:00 GMT

Table of Contents

In a rather indirect way, I was inspired by a commenter on one of Scott Hanselman's posts to begin a series that walks through building a WPF application from start to finish. We did this for four different applications in our book, but those where targeted to demonstrate particular facets of WPF whereas in these (yet unwritten) posts I'd like to focus more on "this is how I build my WPF apps". Not to say that my way is the *right way*, but so that we might learn together. In the spirit of the aforementioned post, I'm bound to make mistakes, so please (gently) correct me when you think you see one.

What to build?

You might not have noticed, but there's quite a bit of .NET chatter in twit-space. There are already lots of Twitter clients, and some are WPF, so that path has been rigorously trod. However, the technical difficulties surrounding Twitter has given rise to the popularity of another mash up web 2.0 thingy app called FriendFeed. Everyone seems to agree that the web interface for FriendFeed is all stinky bad, and there's an API readily available, so I think a FriendFeed client is in order.

Briefly, FriendFeed is a way to consolidate all of your creepy Internet voyeurism in one spot. You can track a friend's Flickr account, NetFlix queue, Amazon wishlist, and yes, their Twitter tweets and much, much more. Oh yeah, and you can subscribe to me here. (I'm such a loser.)

What to do?

I'm not going to set an agenda or outline a detailed plan. I'm just going to post as I have time to work on it. I started tonight, so I'm expecting to have a real Part 1 posted by midweek. I've already set up a project at CodePlex (though it won't be published for a few more days still.) I named it ChumChase. Isn't that great?

Part of my plan is to step you through my thinking and decision making process in sort of Nilssonian way. I've only just begun but here's what I can tell you so far.

I'm going to use a Model-View-Presenter pattern
Expect to see some DDD artifacts.
I'm going to use NUnit and RhinoMocks.
I'll probably use Windsor too (or maybe StructureMap though, anybody have a preference?)

I had intended to write a set of user stories using the issue tracker of CodePlex. However, I got tired of retyping them every time the site errorred out, which was about 60% of the time. (Is that typical for the CodePlex issue tracker? This was my first usage.) It also occurred to me that I am lazy and ought to have a life outside of coding, so sorry no user stories.

What to think?

I'm all about conversation. If this interests you, please let me know. I welcome (friendly) criticisms as well. The more I hear, the more motivated I'll be to do it. (Believe me there's a lot to distract right now. I had a new baby son born on the 10th.)

Continue to Part 1

Phil Haack: Research on TDD

Christopher Bennage — Tue, 22 Jan 2008 16:52:22 GMT

Phil Haack has an interesting post on some research regarding the effectiveness of Test Driven Development. I'm really glad to know that this sort of work is going on, and the results are, er, moderately encouraging to the TDD enthusiast. This topic of research supporting methodologies has been a bit contentious of late. These subjects seem like they would be very difficult to analyze because there are some many factors involved (from skill level of the individual developers to the qualification of 'what good code is'.) Nevertheless, carry on my good researchers!

Now, I want to hook up with a CS department. Anyone out there from the FSU CS department reading this? :-)

TDD Example: Querying a Repository

Christopher Bennage — Mon, 27 Aug 2007 03:07:00 GMT

I'm always a little intimidated when I post code examples. There are a lot of smart (and opinionated) people out there reading blogs. Fear won't get us anywhere though. That said, I'm posting this example and asking for criticism.

Here's the story. A school of music needs to schedule auditions for incoming students. The faculty need to be able to view the schedule for the next two upcoming terms, and some of staff needs to be able to edit the audition schedule.

The "schedule" is really a set of rooms set aside on certain dates for certain types of students. For example, room 1874 will be used for violins on September 21. Thus, a ScheduledRoom is a certain on a certain date, with rules about who can audition there. Right now, we're just concerned with retrieving the list of rooms for a given Term, which is a unique combination of year and semester.

We have a repository for handling audition schedules, and a service that talks to the repository. The service is in turn accessed by a desktop client, and a web client. I'm going to focus on just the repository here.

namespace Specifications.Integrated.The_repository_for
{
    [TestFixture]
    public class the_audition_schedule
    {
        private AuditionScheduleRepository _repository;

        [SetUp]
        public void SetUp
        {
            _repository = new AuditionScheduleRepository();
        }

        [Test, RollBack]
        public void can_retrieve_the_list_of_scheduled_rooms_for_a_given_term()
        {
            //setup data for test
            Term fall2000 = a_term_for_Fall_2000();
            Term spring2001 = a_term_for_Spring_2001();

            schedule_a_room_for_(fall2000);
            schedule_a_room_for_(fall2000);
            schedule_a_room_for_(fall2000);
            schedule_a_room_for_(spring2001);

            //here's the actual code under test
            IList<ScheduledRoom> rooms = _repository.GetRooms(fall2000);

            //verify the results
            Assert.AreEqual(3, rooms.Count);
        }
    }
}

The methods a_term_for_Fall_2000(), a_term_for_Spring_2001(), and schedule_a_room_for_() are helper methods that do nothing more than persist some test data. In my [Setup], I create a new instance of _repository, so that it's fresh for every test.

What am I really testing here? An important question, Joey Beninghove has a good post on the topic here.

I want to ensure that GetRooms() behaves the way I expect. I expect it to return 3 out of the 4 terms I have persisted. The actual implementation for GetRooms() builds an NHibernate.ICriteria and call its List<>() method.

Thoughts? Comments? More examples to come...

Confidence in your code

Christopher Bennage — Thu, 23 Aug 2007 02:53:42 GMT

First, I highly recommend Kent Beck's Test Driven Development: By Example. It's an excellent book.

I mentioned Beck's book, because it is there that I gained an insight affecting the way I'm writing unit tests. (So Christopher, you're saying that one of the seminal works on unit testing has affected the way you are writing tests? Um, yes, I am saying that.)

Kent asks a question about when you should remove duplicate or overlapping tests. His answer was that if it doesn't decrease your confidence in the code, then it's okay to delete it. (I hope I'm getting that right, my copy is loaned out at the moment.)

My current project uses WCF to handle communication from the desktop client to the server. We have a set of interfaces for our services shared in a common assembly. When I create a new interface, I always forget to decorate it with the ServiceContract attribute, or I'll create a DTO and forget the DataContract/DataMember attributes, or (and here's the worst) I'll forget to add the PrincipalPermission attribute to the actual implementation of our services!

This has been bothering me for a month or two, and finally it dawned on me: why don't I write tests for all of this? I'm not confident in the code, I'm fearful that I'm forgetting things; let's write tests and remove the doubt!

Here's what one of the tests looks like:

[TestFixture]
public class Service_interfaces
{
	private const string ASSEMBLY = "SomeAssembly";
	private const string SERVICE_NAMESPACE = "ServiceInterfaces";

	[Test]
	public void must_have_a_ServiceContract_attribute()
	{
		bool atLeastOne = false;

		foreach (Type type in Assembly.Load(ASSEMBLY).GetTypes())
		{
			if (type.Namespace.Contains(SERVICE_NAMESPACE))
			{
				atLeastOne = true;

				object[] attributes = type.GetCustomAttributes(typeof (ServiceContractAttribute), false);
				Assert.IsTrue(attributes.Length > 0,
							  string.Format("The {0} does is not decorated with the ServiceContractAttribute", type));
			}
		}

		Assert.IsTrue(atLeastOne,
					  string.Format("No service interfaces were found in {0} in the namepace {1}.",
									ASSEMBLY,
									SERVICE_NAMESPACE));
	}
}

So I am just the last on the bus? What do you think? Is there a better way to handle this?