ploeh blog

ploeh blog Is Moving

ploeh — Wed, 11 Feb 2009 19:01:18 GMT

After three years on MSDN blogs, I'll be moving my blog to http://blog.ploeh.dk. Why? Read the answer here.

This is most likely the last post on this blog, so if you'd like to stay tuned, please go and subscribe to the new blog.

Faking The Windows Azure Table Service

ploeh — Sat, 24 Jan 2009 13:21:36 GMT

When presented with a new technology, one of my primary evaluation criteria is its testability, so it should come as no surprise to the regular reader of this blog that this was also foremost in my mind when Windows Azure was presented at PDC. Much of the Azure Services Platform is just .NET, so testability is really up to you, just like with all other .NET code.

However, when it comes to the Windows Azure storage, the developer story is different. The Windows Azure Table Service is essentially a REST-based service, and to use it, you'll need to install the Azure Visual Studio SDK.

That's not a problem in itself, but it seems to be implemented as a REST service on top of SQL Server Express. While that may be good enough for casual development, that's quite heavyweight for unit testing. Imagine having to somehow deal with populating and cleaning this database between each test case. That will likely involve a fair amount of complex and undocumented Back Door Manipulation. As the service is out of process in relation to the test, this is brittle and slow, so a better approach is warranted.

Fortunately, I've already demonstrated how to Fake a REST-based Data Service, so faking the Windows Azure Table Service turns out to be fairly easy, and generally follows the same steps as previously outlined.

In the following example, I'm working with a simple service that echoes messages back to the caller. The Delay method saves the input message in table storage and returns the previous message from storage. This test verifies that the input message is being correctly saved:

[TestMethod]

public void DelayWillSaveMessage()

    // Fixture setup

    string expectedMessage = "Anonymous text";

    Uri address = new Uri("http://localhost/EchoService");

    FakeDataService<MessageContainer> service =

        new FakeDataService<MessageContainer>(

            new MessageContainer());

    using (WebServiceHost host =

        new WebServiceHost(service, new[] { address }))

        host.Open();

        StorageAccountInfo account =

            EchoFacadeTest.GetAccount();

        EchoFacade sut = new EchoFacade(() => account);

        // Exercise system

        sut.Delay(expectedMessage);

        // Verify outcome

        Assert.AreEqual<string>(expectedMessage,

            service.Container.GetStore<FakeMessage>().

            First().Message, "Delay");

        // Teardown

In the EchoFacade service, I've used the SDK sample StorageClient library that extents the ADO.NET Data Services Client API to deal with the particulars of Windows Azure Table Storage. One difference from regular ADO.NET Data Services lies in how StorageClient deals with the base URIs of the REST interface. This is a challenge, because a URI like http://localhost/EchoService is interpreted as a service at the address localhost belonging to the account EchoService.

This has the implication that I can't just pass the complete address directly to the client API (i.e. EchoFacade), since it would need to decompose it before it can make proper use of it. Fortunately, such a decomposition already exists in the form of the StorageAccountInfo class, so I just need to pass a properly configured instance to my SUT to make it work.

The test accomplishes this task like this:

private static StorageAccountInfo GetAccount()

    Uri address = new Uri("http://localhost/");

    return new StorageAccountInfo(address, true,

        "EchoService", EchoFacadeTest.TableKey);

When the service is hosted in the full system (whether in the Development Fabric or on Azure proper), the StorageAccountInfo instance is instead initialized using the static StorageAccountInfo.GetDefaultTableStorageAccountFromConfiguration method.

If you are using the StorageClient library for your data access code, you might as well also take advantage of it when defining the fake service. First of all, you can derive the entities exposed from the Fake service from TableStorageEntity, as this gives you the key properties for free.

public class FakeMessage : TableStorageEntity

    public FakeMessage()

        this.CreationTime = DateTime.Now;

    public DateTime CreationTime { get; set; }

    public string Message { get; set; }

The DataContainer then becomes equally simple:

public class MessageContainer : DataContainer

    public IQueryable<FakeMessage> Messages

get

            return this.GetStore<FakeMessage>().

                AsQueryable();

Using a Fake ADO.NET Data Service enables you unit test clients of the Windows Azure Table Service in a light-weight manner.

In this Fake, I have chosen not to deal with the Windows Azure Table Service's particular way of partitioning and sorting data according to PartitionKey and RowKey. Instead, I just rely on the Fixture of each test to insert the data entities in the expected order.

A General-Purpose Fake ADO.NET Data Service

ploeh — Tue, 20 Jan 2009 10:10:00 GMT

In my previous post, I discussed how to implement a Fake ADO.NET Data Service for use with unit testing, showing how you can develop a one-off service that addresses specific needs, such as querying parents and children in the example.

As I hinted in that post, it's possible to create a reusable Fake ADO.NET Data Service that takes care of implementing IUpdatable based on in-memory data storage. To save you the trouble of doing that, I've created one that you can use, if you should so desire.

Following the standard ADO.NET Data Service coding idiom, the Fake ADO.NET Data Service consists of two classes:

FakeDataService<T>, which derives from DataService<T>. This is simply the counterpart of MyDataService from the previous example. You can use this class as is.
DataContainer, which implements IUpdatable. Although I haven't made this class abstract, it only becomes useful when you derive from it and define your own queries.

Let's say that I want to use these two classes to unit test the same service client as in the previous example. Instead of MyService (where I manually had to implement IUpdatable), I can now define my data container as simply as this:

public partial class ParentChildContainer : DataContainer

    public IQueryable<Child> Children

get

            return this.GetStore<Child>().AsQueryable();

    public IQueryable<Parent> Parents

get

            return this.GetStore<Parent>().AsQueryable();

The only thing you have to do is just derive from DataContainer and specify your queries.

Although you don't have to use FakeDataService<T> to host your Fake DataContainer, it makes it easy to set up the Fake service in a unit test:

[TestMethod]

public void TestCanSetupFakeService()

    // Fixture setup

    Uri address = new Uri("http://localhost/MyDataService");

    FakeDataService<ParentChildContainer> service =

        new FakeDataService<ParentChildContainer>(

            new ParentChildContainer());

    using (WebServiceHost host =

        new WebServiceHost(service, new[] { address }))

        host.Open();

        // Exercise system

        // ...

        // Verify outcome

        // ...

        // Teardown

How does this work? DataContainer stores each 'table' in a List<T>, and each list is again stored in a dictionary that maps the list to the type. Here's the part of DataContainer that doesn't contain the IUpdatable implementation:

public partial class DataContainer

    private readonly Dictionary<Type, IList> stores;

    public DataContainer()

        this.stores = new Dictionary<Type, IList>();

    public IList<T> GetStore<T>()

        if (!this.stores.ContainsKey(typeof(T)))

            this.AddStore<T>();

        return (IList<T>)this.stores[typeof(T)];

    private void AddStore<T>()

        this.stores.Add(typeof(T), new List<T>());

When you call GetStore<T>, DataContainer implicitly creates the list for the give type if it doesn't already exist.

The rest of DataContainer deals with implementing IUpdatable:

#region IUpdatable Members

public void AddReferenceToCollection(object targetResource,

    string propertyName, object resourceToBeAdded)

    IList list = (IList)targetResource.GetType().

        GetProperty(propertyName).

        GetValue(targetResource, null);

    list.Add(resourceToBeAdded);

public void ClearChanges()

public object CreateResource(string containerName,

    string fullTypeName)

    Type t = this.ResolveType(fullTypeName);

    object resource = Activator.CreateInstance(t);

    this.stores[t].Add(resource);

    return resource;

public void DeleteResource(object targetResource)

    foreach (IList list in this.stores.Values)

        list.Remove(targetResource);

public object GetResource(IQueryable query,

    string fullTypeName)

    return query.Cast<object>().AsEnumerable().

        FirstOrDefault();

public object GetValue(object targetResource,

    string propertyName)

    return targetResource.GetType().

        GetProperty(propertyName).

        GetValue(targetResource, null);

public void RemoveReferenceFromCollection(

    object targetResource,

    string propertyName,

    object resourceToBeRemoved)

    IList list = (IList)targetResource.GetType().

        GetProperty(propertyName).

        GetValue(targetResource, null);

    list.Remove(resourceToBeRemoved);

public object ResetResource(object resource)

    return resource;

public object ResolveResource(object resource)

    return resource;

public void SaveChanges()

public void SetReference(object targetResource,

    string propertyName, object propertyValue)

    targetResource.GetType().GetProperty(propertyName).

        SetValue(targetResource, propertyValue, null);

public void SetValue(object targetResource,

    string propertyName, object propertyValue)

    targetResource.GetType().GetProperty(propertyName).

        SetValue(targetResource, propertyValue, null);

#endregion

private Type ResolveType(string fullTypeName)

    return (from t in this.stores.Keys

            where t.FullName == fullTypeName

            select t).First();

If you find this useful, I've attached the code to this post for your downloading pleasure. As always, the standard disclaimers apply.

Creating A Fake ADO.NET Data Service

ploeh — Mon, 19 Jan 2009 11:00:00 GMT

Previously, I discussed unit testing ADO.NET Data Service clients using a Fake ADO.NET Data Service, and I promised to demonstrate how to create such a service. In this article I will continue the previous example and implement the Fake MyService class.

The basics of MyService is pretty simple:

public partial class MyService

    public MyService()

        this.ParentStore = new List<Parent>();

        this.ChildStore = new List<Child>();

    public IQueryable<Child> Children

        get { return this.ChildStore.AsQueryable(); }

    public IQueryable<Parent> Parents

        get { return this.ParentStore.AsQueryable(); }

    public IList<Child> ChildStore { get; private set; }

    public IList<Parent> ParentStore { get; private set; }

This service supports two 'tables': Parents and Children (Parents can have Children). Since this is a Fake, it only needs to store its data in memory, so I use two List<T> instances for that. To provide direct access to the service's data, MyService exposes both lists as public properties (you can make those properties internal if your Fake service is defined in the same assembly as your tests).

This is all you need if you only need to support read-only scenarios. If the client you want to test only queries its service, you don't need to do anything else. On the other hand, if you also need to test Create, Update and Delete (CUD) operations, you will need to implement IUpdatable:

public partial class MyService : IUpdatable

Implementing this interface enables you to support CUD operations. Since it contains twelve members, I'm not going to walk you through each and every one of them, but rather present some highlights. If you are interested in more details on the methods of this interface, I'll recommend this post on the Project Astoria Team Blog.

To support each of the simple CUD operations, multiple methods must be implemented, although there's an overlap.

To create a new item, the first method to implement is CreateResource.

public object CreateResource(string containerName,

    string fullTypeName)

    switch (containerName)

        case "Parents":

            Parent p = new Parent();

            this.ParentStore.Add(p);

            return p;

        case "Children":

            Child c = new Child();

            this.ChildStore.Add(c);

            return c;

        default:

            throw new ArgumentException(

                "Unknown container name.");

This implementation simply creates a new instance of the requested item type and adds it to the in-memory list. Here, I was just being a bit lazy and simply switched on the containerName, but it's perfectly possible to create a more generic implementation using a bit of Reflection, since the fullTypeName parameter specifies which type of object to create.

The CreateResource method's responsibility is to create a default instance of the requested type and add it to the underlying data store (in this case just an in-memory list). However, it doesn't assign values to the item's properties, since this is the duty of the SetValue method.

public void SetValue(object targetResource,

    string propertyName, object propertyValue)

    Type t = targetResource.GetType();

    t.GetProperty(propertyName).SetValue(

        targetResource, propertyValue, null);

At this point, I found it easier to implement the method using Reflection than explicitly switching on both the targetResource and propertyName parameters.

The last method that must be implemented to support the Create scenario is ResolveResource.

public object ResolveResource(object resource)

    return resource;

Since the Fake service is already working with in-memory objects, it can just return the object itself.

With these methods implemented, updating an item is not quite as involved, since it reuses the SetValue and ResolveResource methods, so I only need to implement the GetResource method.

public object GetResource(IQueryable query,

    string fullTypeName)

    return query.Cast<object>().AsEnumerable().

        FirstOrDefault();

This implementation requires a bit of explanation. The query argument that the method receives is actually an expression over the service's exposed queries (i.e. Parents and Children). Since the service operates on in-memory objects, it doesn't need to transform the expression, but can simply evaluate it directly, which is what the AsEnumerable extension method does. However, IQueryable doesn't have an AsEnumerable extension method, whereas IQueryable<T> does - hence the cast to object.

Deleting an item reuses GetResource and ResolveResource, so to support this scenario, the DeleteResource method is the only extra method that must be implemented.

public void DeleteResource(object targetResource)

    ((IList)this.ParentStore).Remove(targetResource);

    ((IList)this.ChildStore).Remove(targetResource);

Once again, I decided to keep things simple and simply hard-code knowledge of ParentStore and ChildStore into the method, but it would be easy to generalize this approach.

The rest of the methods of IUpdatable address more advanced scenarios concerning references between items, and I'm not going to cover them in this post, since it's already becoming quite long. If you are interested, I've provided the entire sample code as an attachment to this post, so download and peruse it at your leisure (obviously, the usual disclaimers apply).

Update: I've now posted a general-purpose Fake ADO.NET Data Service that should hopefully address most of your needs.

Unit Testing ADO.NET Data Service Clients

ploeh — Wed, 14 Jan 2009 18:51:13 GMT

In my previous post, I discussed unit testing ADO.NET Data Services and how you can host and test the service itself. In this post, I'll take a look at the opposite scenario: You have a client of an ADO.NET Data Service, and you want to unit test the client without relying on the real, production service.

In other words, you want to test the real client against a Test Double service. Presently, I'll show you how to create and host a Fake ADO.NET Data Service that the client code can invoke. Obviously, the client in this example uses the ADO.NET Data Services Client API, so I'll demonstrate how you can use that to invoke the fake service from within the same test.

Before we dive into the specifics of the implementation, here's a simple test that verifies that the client can retrieve all Parent instances from the service:

As you can see from the figure, the test combines two logical tiers into one test: The service and the client.

The service tier is simply part of the test's Fixture, and while I'm not concerned with testing it in this context, I still need to set it up. This part uses the ADO.NET Data Services API to define and host the service.

The client part uses the ADO.NET Data Services Client API to query the service via its REST interface and verify the result.

Notice that I use an instance of MyDataService to configure the host. While not strictly necessary in this test, when hosting a Fake service, it's desirable to have a reference to the fake instance itself, since that allows you to configure and query it through its Back Door. Here's a test that uses the MyDataService instance to verify that a Parent instance was deleted from the service:

[TestMethod]

public void ClientCanDeleteInstance()

    // Fixture setup

    Uri address = new Uri("http://localhost/MyDataService");

    MyDataService service = new MyDataService();

    using (WebServiceHost host =

        new WebServiceHost(service, new[] { address }))

        host.Open();

        MyDataServiceContext ctx =

            new MyDataServiceContext(address);

        var victim = (from p in ctx.Parents

                      where p.Id == 3

                      select p).Single();

        // Exercise system

        ctx.DeleteObject(victim);

        ctx.SaveChanges();

        // Verify outcome

        Assert.IsFalse(service.Data.Parents.Any(

            p => p.Id == victim.Id), "Deleted");

        // Teardown

As in the previous example, all Fixture Setup before the declaration of the MyDataServiceContext instance is part of the logical service tier, while the remaining Fixture Setup code, as well as the execution of the SUT is part of the logical client tier. However, notice that the verification now takes place on the logical service tier, since I'm using the fake service instance as a Back Door, instead of relying on the REST interface to query the service.

Since DataServiceHost doesn't include a constructor that takes a single instance as a parameter, I use its base class WebServiceHost instead. Reflector shows that DataServiceHost really adds no behavior to its base class, so using WebServiceHost as a host should be safe - for now (let's hope it stays that way, or even better, that it gets a constructor overload that accepts a service instance).

In normal cases, I consider it best practice to explicitly load data into the fake service as part of the Fixture Setup phase, but to keep these examples simple, I decided to implicitly load some test data as part of creating the MyDataService instance. That is why, in the above example, I can successfully retrieve a Parent instance with an Id of 3. Please be aware that this is not a strategy I endorse - I only did it to keep the example a bit less complex.

Here's the MyDataService class in its entirety:

[ServiceBehavior(IncludeExceptionDetailInFaults = true,

    InstanceContextMode = InstanceContextMode.Single)]

public class MyDataService : DataService<MyService>

    private readonly MyService service_;

    public MyDataService()

        this.service_ = new MyService();

        IList<Parent> ps = this.service_.ParentStore;

        ps.Add(new Parent() { Id = 1, Text = "Ploeh" });

        ps.Add(new Parent() { Id = 2, Text = "Fnaah" });

        ps.Add(new Parent() { Id = 3, Text = "Ndøh" });

        ps.Add(new Parent() { Id = 4, Text = "Foo" });

        ps.Add(new Parent() { Id = 5, Text = "Bar" });

        IList<Child> cs = this.service_.ChildStore;

        cs.Add(new Child() { Id = 1, Text = "Child 1" });

        cs.Add(new Child() { Id = 2, Text = "Child 2" });

        cs.Add(new Child() { Id = 3, Text = "Child 3" });

    public MyService Data

        get { return this.service_; }

    public static void InitializeService(

        IDataServiceConfiguration config)

        config.SetEntitySetAccessRule("*",

            EntitySetRights.All);

        config.UseVerboseErrors = true;

    protected override MyService CreateDataSource()

        return this.service_;

As I described, I use the constructor to set up some implicit test data. While I want to reiterate that this is not something I would recommend, I chose to include this code to make it clear what I was talking about.

The service is decorated with the ServiceBehavior attribute, which sets its InstanceContextMode to Single to allow it to be hosted as a Singleton service by WebServiceHost. This, again, is what allows me to query the fake service's data via its Back Door.

Since MyService simply stores data in memory, MyDataService needs to keep the same instance around for each request, so it overrides CreateDataSource to ensure that the same data container instance is always being referenced for the lifetime of the instance.

In a later post, I will describe how to create the fake data service, MyService.

Unit Testing ADO.NET Data Services

ploeh — Tue, 13 Jan 2009 15:05:00 GMT

ADO.NET Data Services enables you to expose data (including, but not limited to, relational data) as REST services. Since it's built on top of WCF, it can be tested utilizing similar techniques, but allow me to elaborate a bit on the subject.

As with WCF, you might be interested in testing one or both tiers:

The service
The client

Testing the service is the simplest undertaking, so I'll start with that and return to testing the client in a later post.

Why would you want to unit test an ADO.NET Data Service?

The mainstream scenario for ADO.NET Data Services is to expose a relational database using an ADO.NET Entity Model. Is it relevant to unit test such a service? Perhaps not. It depends on the amount of code you inject into the generated (partial) classes. If the amount of custom code is minimal, it may not make much sense to test simple CRUD operations.

Conversely, if you have a greater degree of custom code, or if you implement an ADO.NET Data Service using non-relational data, it makes a lot of sense.

My loyal readers will probably (correctly) suspect that I would tend to expose a Façade over a Domain Model as a data service, which implies going the non-relational route (even if the underlying data store is, in fact, relational). That is also the context for the rest of this post.

First of all, you should keep in mind that the data service is just a normal class, so you can test much of its functionality by just creating it and start using it:

[TestMethod]

public void ServiceCanReturnRequestedItem()

    // Fixture setup

    int anonymousId = 3;

    string expectedText = "Ploeh";

    Parent anonymousParent = new Parent();

    anonymousParent.Id = anonymousId;

    anonymousParent.Text = expectedText;

    MyService sut = new MyService();

    sut.ParentStore.Add(anonymousParent);

    // Exercise system

    Parent result = (from p in sut.Parents

                    where p.Id == anonymousId

                    select p).Single();

    // Verify outcome

    Assert.AreEqual<string>(expectedText, result.Text,

        "Text");

    // Teardown

Notice how most of the test just contains code setting up the Fixture by adding the relevant data to the service's underlying data store, while execution and verification is quickly accomplished.

At some point, however, you will probably want to test the service through its REST interface. To do this, you must host the service within the test and then invoke it.

Hosting the service in a test is easy:

[TestMethod]

public void TestCanHostService()

    // Fixture setup

    Uri address = new Uri("http://localhost/MyDataService");

    using (DataServiceHost host =

        new DataServiceHost(typeof(MyDataService),

            new[] { address }))

        host.Open();

        // Exercise system

        // ...

        // Verify outcome

        // ...

        // Teardown

Since the service is exposed through a REST interface, you can use more than one technology to invoke it. The ADO.NET Data Services client API is a natural fit, and I'll cover this in a later post. For now, just imagine that the test above contains client code that invokes the service and verifies the result.

As it turns out, unit testing an ADO.NET Data Service isn't particularly difficult. Unit testing ADO.NET Data Service Clients is a bit more involved, so I'll cover that topic in a separate post. Update: This post is now available here.

Test-Driven Properties

ploeh — Mon, 12 Jan 2009 11:26:00 GMT

Zero-Friction TDD post #10:

In principle, defining properties (or fields, for that matter) while TDD'ing should be no different than defining methods. Again, the important part is to stay focused on the test at hand, and not become bogged down by implementation details.

Unfortunately, neither Visual Studio 2005 nor 2008 has a Generate property stub smart tag, so until the day arrives when we get support for such in our IDE of choice (and for the record: I have no idea about when this is going to happen), we'll have to resort to more primitive means:

Just reference the non-existing property and move on:

As you can see from the picture, my test code gets squiggly lines under the MyProperty property because this property doesn't exist (yet).

Once more, the important point is to move on and resist the urge to fix this immediately. Don't even waste memory (your own, that is) on the fact that you need to implement this soon; just forget about it right away. The compiler will remind you in due time.

This technique is a essentially what Michael Feathers calls leaning on the compiler, although the context is different.

Use The Generate Method Stub Smart Tag To Stay In The Zone

ploeh — Mon, 05 Jan 2009 11:53:00 GMT

Yet Another Zero-Friction TDD Article (YAZFTA):

When writing unit tests in the TDD fashion, it's important to stay in the zone and not get side-tracked by irrelevant issues. You need to avoid what I call mental context switching. Focus on writing the test and postpone all else to later, but make sure that you do it in such a way that you don't have to waste brainpower on remembering what you postponed.

One easy way to do this is by using the Generate method stub smart tag in Visual Studio:

As we all know, this will generate the following implementation in MyClass:

public void MyMethod()

    throw new NotImplementedException();

but since you already know that, you don't have to go look at it, and you don't even need to commit to memory that you will have to implement the method. When you run the test, it's going to throw a NotImplementedException, and that's all the reminder you need.

So just use the smart tag and move on. Right away, forget about the method you just created. Resist the temptation to go implement it immediately, no matter how simple it might be. Stay focused on writing the test.

You can use the same technique when it comes to evolving SUT API Encapsulation: Sometimes, I know that I'd really like a test helper method that can do something for me, but I have only a vague idea about how to implement it. In such cases, I just write the name of the method, use the smart tag and move on. This helps me stay focused on writing the test, and I can always come back later and implement the helper method at a more convenient time.

Assert Messages Are Not Optional

ploeh — Wed, 17 Dec 2008 15:08:00 GMT

...and now, in this week's episode of Zero-Friction TDD: Optional Assert messages that aren't optional anyway!

Actually, this piece of advice comes almost directly from the xUnit Test Patterns book, so I was in doubt whether I should post it all, but it bears repeating, and I guess I still have a few things to add.

The various Assert methods all have an overload that takes a message string that is basically just echoed to the Test Results list if the test fails, appended to the assertion's more generic message.

For example, this assertion

Assert.AreEqual<string>(expectedResult, result, "DoStuff");

will produce this output:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>. DoStuff

As there are also overloads available that does not take such a message string, it is tempting to treat it as optional. As far as the compiler is concerned, I might as well have written this:

Assert.AreEqual<string>(expectedResult, result);

which would have yielded this output:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>.

Not much of a difference, so it may seem quite redundant to supply this extra message.

Well, not only will I argue that it provides value, I will even go so far as to insist that you should treat it as mandatory. Here's the reason:

When one or more test failures appear in the Test Results window, my eyes naturally seek out the Error Message text, so it's very nice to have all the information I need present in the same context. All I really need is just a small hint that will jog my memory enough so that I know what I did wrong.

Please note that I'm not really talking about using the message in the initial Red/Green/Refactor development cycle. In this phase, I rarely read the test failure text at all - I only register that there was a failure, which was expected, since the code isn't implemented yet.

I'm talking about what happens when you refactor a code base with hundreds of tests. In such cases, I often inadvertently break existing tests, and my eyes immediately seek out the Error Message.

Imagine that this is the error message:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>.

All this really tells me is that in one of my tests (and I don't know which one yet), something was expected to have the value ploeh, but ended up having no value. That's not a lot to go after, so I will probably have to open the test and read it through to get enough context to know what I broke.

On the other hand, I've experienced that just a little extra message often provides just enough context that I immediately realize what I broke:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>. DoStuff

In this case, DoStuff is the name of the method being tested. It may seem hard to believe, but in most cases, this is context enough to help my brain figuring out what went wrong. Keep in mind that the test failure was a result of a code change that I just implemented, so my mind has a lot of context already, and it needs almost no help to make the final connection.

When I first encountered this guidance, I was sceptic, but after having worked with it for some time, I'm not going back. It has increased my productivity while refactoring, because I don't need to investigate failure causes quite as often as I did before.

Most developers dislike having to write this optional message because they feel that they ought to write a long piece of fluent prose. That's not the case: Just write a single cue that can trigger your brain at a later date. Normally, I just write the name of the method or property I'm testing - I find that I can easily do that and still stay in the zone when I'm writing my tests.

You are probably still skeptical, but try it out for a couple of months and see what you think!

First Dynamics Mobile Post

ploeh — Fri, 12 Dec 2008 18:00:51 GMT

Yesterday, I posted my first post over on the Microsoft Dynamics Mobile Team blog. More are likely to follow.

In case you are wondering what this means for this blog, the answer is: Nothing. I plan to continue blogging in more or less the same vein as I've done for the last three years now.