I found a good use for the InlineData xUnit attribute:

public class DateDiffCalculatorFacts
{
    [Theory,
    InlineData("2008-09-25 14:31", "1 minute"),
    InlineData("2008-09-25 15:05", "35 minutes"),
    InlineData("2008-09-25 16:05", "1 hour 35 minutes"),
    InlineData("2008-09-25 17:05", "2 hours 35 minutes"),
    InlineData("2008-09-25 19:05", "4 hours"),
    InlineData("2008-09-25 02:30", "12 hours"),
    InlineData("2008-09-24 00:00", "1 day 14 hours"),
    InlineData("2008-09-23 00:00", "2 days 14 hours"),
    InlineData("2008-09-20 00:00", "5 days"),
    InlineData("2008-08-20 00:00", "1 month 5 days"),
    InlineData("2008-07-01 00:00", "2 months 24 days"),
    InlineData("2008-05-01 00:00", "4 months"),
    InlineData("2007-07-20 00:00", "1 year 2 months"),
    InlineData("2005-07-20 00:00", "3 years")]
    public void Can_get_correct_age_for_date(string dateString, string expectedAge)
    {
        var date = DateTime.Parse(dateString, CultureInfo.InvariantCulture, DateTimeStyles.None);
        var referenceDate = DateTime.Parse("2008-09-25 14:30:00", CultureInfo.InvariantCulture, DateTimeStyles.None);

        var calc = new DateDiffCalculator(date, referenceDate);

        string age = calc.ToString();
        Assert.Equal(expectedAge, age);
    }
}

This is the first time I have used this style of testing (called RowTests in MbUnit/NUnit). Maybe in this case it is not the right thing to do from a pure TDD perspective as the test name is not very descriptive of what is being tested. If each InlineData was extracted to a sepereate test they could be given more meaningfull names like "Measure_will_be_in_plural_when_more_than_one" and "Skip_sub_measure_when_main_measure_is_higher_than_two". On the otherhand having the test like above made it dead simple and fast to add new test cases and it still quite apparenent what the intended outcome is.