James Broome

I’m a big fan of anything that can make me work faster – working on an agile project can be at quite a hectic pace and anything that can save me a couple of minutes, especially if its something I do often is a good thing.

I spoke at our last community day about Behaviour Driven Development and why I thought it really fitted with agile processes. After the session a colleague commented on my use of the keyboard and even went as far as to say he was impressed that I hadn’t used the mouse at all when demo-ing the code I was talking about. Now a compliment is a compliment and I’ll take it, but I actually remember thinking at the time that I was being really clumsy and slow – I think my nerves got to me a bit talking in front of 40 or so people, and everyone knows that you can’t type when someone’s watching!

But it got me thinking that as I’ve been using ReSharper for about a year or so now that was I starting to take it for granted that everyone else had too.

So, I thought I’d expand on that a little and compile a short list of tools that I use on a daily basis that makes my life easier and quicker. There’s generally a learning curve involved in each one, even just adjusting your mindset to not reach for the mouse! This isn’t entirely altruistic, as I’m really looking for suggestions on more!

Launchy

When you really get into the keyboard mindset, you want to start using it for every application. This tool enables you to launch any application without the need to reach for the mouse, so your fingers are ready to go as soon as it fires up! Alt+Enter is the default shortcut. Type “firefox” and hit Enter to launch the next tool… (after a few times, Launchy predicts what you want as you type, so I can now launch Firefox with just an “f”).

Firefox extensions

So everyone knows that Firefox is awesome, but for me its the extensions that make it totally indispensable.  Here’s a few that I use:

Firebug

I don’t know how anyone can be a web developer without it. No more hours spent tweaking CSS files and hitting F5 to find that you have no idea what you’re actually doing and that you really don’t understand CSS. I can now muck in with the iDevs (although there is an argument for saying that a little knowledge in the wrong hands is a dangerous thing!)

Hit a Hint

A keyboard navigation extension for Firefox. Who said that you had to use the mouse when browsing the web?! Just hit “h” and watch numbers appear by every link on the page. Type your number, hit enter and away you go.

Google toolbar

Not really an extension as such but gives you the ability to search Google from any page within Firefox. Ctrl+K to jump straight to it, and a cheeky Alt+Enter opens the results in a new tab. Nice.

So, if we start to string them together – you’ve got an Alt+Space, an f for Firefox and Enter in Launchy, a Ctrl+K, enter your search term and hit enter. How often do you search Google in a day? Even shaving 10 seconds off this is going to save years in your life! (I have not actually worked this out).

UPDATE! Woah! – in the space of writing this post, I’ve just learnt that there’s an even quicker way through Lanuchy :

Alt+Enter, “google”, Tab, “Search term”, Enter and there you go – even quicker. And once you’ve done this once, Launchy is predicting that you want Google after “goo” so you don’t even have to type it out in full.

Delicious Bookmarks

If, like me, you use Delicious to manage you bookmarks, you can use the Delicious Bookmarks extension to access them directly through Firefox. No more manual synchronisation between laptops – you can even hide the standard bookmarks menu to ensure that all links are stored in the cloud. And there’s lots of nice keyboard shortcuts to jump to and tag new links.

iMacros

If you’re a web developer and spend a lot of time repeating the same repetitive tasks over and over again to test your site, use this to automate anything possible. On my current project, I often have to launch the site and log in before I can test some functionality, so I have a macro that does this for me.

I no longer have to wait for the application to spin up before I click Log In and manually enter the info, instead I can use the macro to do this for me whilst I get on with something else.

The beauty of these macros is that they can be bookmarked (and it integrates with Delicious) so I can access them from anywhere and by using the keyboard.

TestDriven.Net

On my current project we use the MSTest automated test tools that are integrated within Visual Studio. Whilst I believe that one testing framework is fairly similar to another, I really dislike the Test View and other test management windows that you get with MSTest. Test Driven.Net integrates with MSTest so that you can pop-up a menu using the right-click button or a keyboard shortcut and run the tests directly from where you are. Also the Repeat Test Run option is really good for doing just that, from wherever you are in the solution.

ReSharper

So I’ve saved the best (beast?) till last. If could go on and on about how much I love ReSharper how I could no longer work without it. I’m not going to list out why its awesome as it would take too long, but if this is new to you then I would start by reading this:

http://blog.excastle.com/2007/01/31/blog-event-the-31-days-of-resharper/

and then watching some of this:

http://www.jameskovacs.com/blog/BecomingAJediPart3OfN.aspx

I would consider myself an intermediate ReSharper user – able to make someone’s day with a helpful shortcut thrown in when pair programming or just looking over someone’s shoulder, but I’m still far from being a Jedi as they say.

Through working at Conchango, in the last 6 months I’ve had the pleasure of meeting both Oren Eini and Jean-Paul Boodhoo and watching them code first hand and it really is mind blowing stuff. Hopefully this post has had even just a fraction of the impact that those situations had on me in realising what is possible and that constant self improvement is a scary but awesome thing!

As I mentioned in my first post (and will probably continue to do so for the unforeseeable future), I recently attended JP Boodhoo’s Nothin’ But Dot Net training ‘boot camp’ which has motivated me to start to write about some of the stuff that I learnt and am still trying to make sense of…

The main focus of the course was using Behaviour Driven Design to drive out an application, tests first, from the top down. I was very familiar with the concept of automated unit testing, having used NUnit in the past and using the MSTest tools on my current project. However, I don’t think I could truly say that I’d been working ‘test first’ or that the design of our application was driven out by the test cases. Also, if I were to give a summary report of our automated tests to one of our Business Analysts, I guarantee that it would be met with a blank expression. This makes it tricky to prove that the tests are correct – do they match the requirement and, if this changes, what tests need to change to reflect this?

The whole idea behind BDD is to write tests in plain English, describing the behaviours of the thing that you are testing. When the things that you are testing are written in the common language of the domain, the tests are then describing the behaviour of that domain. The main advantage of this is that the tests reflect the user stories, the business requirements of the application. Careful choice of naming conventions and syntax mean that a unit test report can read like a functional specification. Therefore, it can be read by a non-technical person e.g. the project sponsor, a domain expert, a business analyst and the tests can be validated against the requirements. If a new developer joins the team, they may not know the domain of the application however looking at the tests will immediately give them a very clear idea of the intent of the code.

Let’s take the following hypothetical user story for a staff telephone directory application:

“As a user I should be able to view an alphabetical list of the employees so that I can quickly find the person I wish to contact.”

We may start with writing a test class something like this…

using System;

using System.Collections.Generic;

using Observation = MbUnit.Framework.TestAttribute;
using Context = MbUnit.Framework.TestFixtureAttribute;

[Concerning(typeof(DirectoryTasks))]
public class when_the_directory_tasks_is_told_to_get_all_the_employees_beginning_with_the_letter_A : SpecificationContext
{
    private IEnumerable<Employee> results;
    private IDirectoryTasks sut; //sut = System Under Test    

    protected override void establish_context()
    {
        //Test set up here e.g. mock objects etc...        
        this.sut = new DirectoryTasks();
    }

    protected override void because()
    {
        this.results = this.sut.GetEmployeesBeginningWith("A");
    }

    [Observation]
    public void should_ask_the_telephone_directory_for_all_the_employees_that_begin_with_A()
    {
        //Interaction based test checking that we are talking to the TelephoneDirectory domain object    
    }

    [Observation]
    public void should_return_the_list_of_employees_in_alphabetical_order()
    {
        //State based test  
    }
}

Note the name of the test class describes the context of the tests. The test methods (observations) are describing the expected behaviour of the thing that we are testing. Note too the Arrange, Act, Assert style of the test. We establish the context for the test, perform the action that we want to test and then assert the correct behaviours of the system under test.

Writing the specification first drives out the need for the following supporting domain classes:

public class DirectoryTasks : IDirectoryTasks
{
    public IEnumerable<Employee> GetEmployeesBeginningWith(string first_letter)
    {
        throw new NotImplementedException();
    }
}

public interface IDirectoryTasks
{
    IEnumerable<Employee> GetEmployeesBeginningWith(string first_letter);
}

public class Employee {}

And the test class uses the following utility classes:

/// <summary>
/// Base class for all test contexts - enforces the Arrange, Act, Assert style testing
/// </summary>
[Context]
public abstract class SpecificationContext
{
    [SetUp]
    public void Setup()
    {
        this.establish_context();
        this.because();
    }

    protected abstract void because();
    protected abstract void establish_context();
}

/// <summary>
/// Attribute used in grouping observations
/// when generating test report
/// </summary>
[AttributeUsage(AttributeTargets.Class)]
public class ConcerningAttribute : Attribute
{
    private readonly Type concern;

    public ConcerningAttribute(Type concern)
    {
        this.concern = concern;
    }

    public Type Concern
    {
        get { return this.concern; }
    }
}

Each test class relates to a specific context for a set of tests, which translate as the specification for the system under test. So, you may have more than one test class for each thing that you are testing if there are different test contexts e.g.

when_the_directory_tasks_is_told_to_get_all_the_employees_in_a_department

when_the_directory_tasks_is_told_to_get_all_the_employees_with_a_specific_last_name

And each test context may have multiple tests, or observations, each with different assertions. The assertions themselves can also follow the same BDD coding styles so instead of the typical

Assert.IsTrue();

Assert.AreEqual();

We can use

results.should_only_contain();

result.is_equal_to();

dependency.was_told_to();

Of course, the fluent syntax of the code in the above examples is made possible by the goodness of C# extension methods and some creative thinking about the design and naming of classes. But taking the mantra Red, Green, Refactor, the only thing preventing you from writing truly expressive code is your own creativity. Write the code how you want to use it from the tests, get the code compiling, get the test passing, then refactor the code.

Writing the tests first drives out the code from the top down, whilst writing them in a BDD style syntax gives a meaning to why the tests are there and why that piece of ‘real’ code should then be written. As I’m already working in an agile environment, collaborating with business analysts and working from user stories, developing features in this way just seems to totally fit. Its only a small step to produce a report of all the tests, parsing the class and method names to give you something like this:

1. Directory Tasks

When the directory tasks is told to get all the employees beginning with the letter A

• should ask the telephone directory for all the employees that begin with A
• should return the list of employees in alphabetical order
• should return the list of employees in groups of 10

When the directory tasks is told to get all the employees in a department

• should etc…

Look familiar? The tests start to become a direct specification for the system that can be read, understood and validated by any member of the team. They are written in the language of the domain and describe the behaviour of the domain. If the specification changes, or new requirements are added (or missing) it is easy to see which tests and therefore what code needs to change. The code itself becomes the living breathing documentation of the application and this really supports an agile iterative cycle of development, adding new features one at a time.

Please note: The example above will compile, but the tests won’t yet pass due to the GetEmployeesBeginningWith() method throwing a NotImplementedException. In future posts I will build on this example to flesh out the tests and the associated code.

The test framework used here is MBUnit, so a reference is needed to MBUnit.Framework. Alternatively, the test framework can be replaced by changing the aliases in the using statements at the top of the file.

For more info, see http://behaviour-driven.org/