Unit Test Naming Conventions

When I started writing unit tests I followed the standard of stating the behavior under test in the name of the test method. It was something like what Roy Osherove talks about in this 2005 post and has the following format:

[MethodName_StateUnderTest_ExpectedBehavior]

It worked reasonably well most of the cases, but sometimes, probably due to an effort in maintaining the name within a reasonable length the results were less than satisfying or I would spend too much time trying to get the name right.

Having decided to try a different approach I searched the web looking to find out how others were tackling this situation and what unit test naming guidelines they were using. In general it would all come to the same descriptive method name until I found a very interesting read in this post by Jay Fields. He compares test names to glorified comments and talks about anonymous tests.

Completely anonymous tests would be something of an extreme measure for me and the unit test framework being used doesn’t even support it (NUnit). However it kind of inspired me to try my own simplified approach which ended up like this:

[MethodName_TestID]

and where each test method has an associated description clearly stating the behavior under test. This way the method name remains concise and in the case of a test failing I rely on the test runner report (Gallio) to include the associated description thus allowing to quickly understand what went wrong.

Gallio Failed Test Report
Gallio Failed Test Report

Throw in a visual studio snippet to quickly define a new unit test with the custom format and we are ready to go.

Advertisements

MS Project 2007 – Project Open Event with VSTO 3.0

Recently I got my self into a situation where I needed to develop a MS Project add-in using VSTO, but the fun doesn’t stop here. Also included in the package was the migration of some VB macros to the freshly developed add-in.

Because of this code migration I needed to perform some actions when opening a project file but I could not find an event handler at the application (add-in) level.

So here is how I ended up implementing it:

private void ThisAddIn_Startup(object sender, EventArgs e)
{
    this.Application.NewProject += 
        new MSProject._EProjectApp2_NewProjectEventHandler(
          Application_NewProject);
}

private void Application_NewProject(MSProject.Project pj)
{
    pj.Open += new MSProject._EProjectDoc_OpenEventHandler(
        Project_Open);
}

private void Project_Open(MSProject.Project pj)
{
    string message;
    message = String.Format("Opened project {0}.", pj.Name);

    MessageBox.Show(message);
}

One adjective to rule them all

ex·cep·tion·al

  1. Being an exception; uncommon.
  2. Well above average; extraordinary.
  3. Deviating widely from a norm.
  4. Strange.
  5. Anomalous.

In the last couple of months the idea of creating a blog crossed my mind several times and now I’m finally doing it just because today I found a name that sounds nice, has a cool twist and is also suitable for what this blog will be about.

And what exactly is this blog about? Yes, you guessed it, it’s about code (mostly .NET).  The reason behind this adventure is a mix between giving something back to the community and the feeling that this is something that will really ease my evolution as a developer.

Finally, as a disclaimer, I’ll be aiming for definition number two but this blog will probably contain entries that will pretty much encompass all the above definitions for exceptional.