Goofy TDD Construct

Test-driving methods in C# or Java often requires variant values for a given primitive argument:

[Test]
public void ShouldGenerateAppointmentsOnMonthBoundariesByDefault() {
   var appointments = new QuarterlyRule(4);
   Assert.That(...);
}

[Test]
public void ShouldGenerateAppointmentsOnSpecifiedDayOfMonth() {
   var appointments = new QuarterlyRule(2, 15);
   Assert.That(...);
}

The numbers (4, 6, 15, …) are magic, but there are numerous ways of clarifying things for the reader. We could “encode” them in the test name, but I’ve found that simply clutters the name, making it even harder to quickly digest. Test names should be as implementation-free as they can be, within reason. They should capture the behavior in an abstract sense.

We could introduce a variable–either local or more global–that clarifies things. Here are two examples:

[Test]
public void ShouldGenerateAppointmentsOnMonthBoundariesByDefault() {
   const int recurrences = 4;
   var appointments = new QuarterlyRule(recurrences);
   Assert.That(...);
}

const int RECURRENCES = 2;
[Test]
   public void ShouldGenerateAppointmentsOnSpecifiedDayOfMonth() {
      var appointments = new QuarterlyRule(RECURRENCES, 15);
      Assert.That(...);
}

Hmm. The problem with the global constant in this case is that it imparts only half the meaning. If the 6 is relevant to the ultimate assertion (and it probably should be in order to be part of a meaningful test), and that value is hidden, it forces the reader to navigate in order to completely understand the test. We can rename the constant:

   const int TWO_RECURRENCES = 2; // or ...
   const int RECURS_QUARTERLY_ACROSS_HALF_YEAR = 2;

… but those names are unsatisfying. The first is somewhat silly, and the second is too clever, demanding a bit too much effort from the reader.

An explaining temporary variable can be acceptable, but it is disappointing to waste an entire line just to document an argument, particularly if you have a good number of tests that require the variance. And particularly if you have tests that would otherwise be one-liners or three-liners (arrange-act-assert).

Other solutions? You could stuff a comment (horrors!) into the call:

   var appointments = new QuarterlyRule(/*recurrences*/ 4);

No thanks. You could encode the parameter in the method name (in this case, using a constructor factory method):

   var appointments = CreateQuarterlyRuleWithRecurrences(4);

Sometimes that’s appropriate, other times it is burdensome to the production code. You could punt and use a better language:

   appointments := QuarterlyRule new recurrences: 4 dayOfMonth: 15.

Am I missing any other options? Perhaps. The one I chose to do today, in an act of whimsy:

[Test]
public void ShouldGenerateAppointmentsOnMonthBoundariesByDefault()
{
   var appointments = new QuarterlyRule(Recurrences(4));
   Assert.That(...)
}

int Recurrences(int number) { return number; }

Is this nuts or what? So far I’ve used it in one test class; I can imagine it could become onerous to create numerous such methods. But for now I plan on constraining use of it to situations that require pervasive use, across a good number of test cases.

Thoughts? Rotten eggs?

Blogger -> WordPress

Until recently I used Google’s Blogger for creating posts and publishing them to my site via FTP. Google decided that they wanted to focus support on blogs hosted by them and on blogs existing on a custom domain, claiming that the FTP solution was too much trouble to support. Unfortunately, they provided no solution for seamlessly meshing their blog product with my existing site.

I’ve decided to move to WordPress, since it’s the only one of three solutions provided by my ISP that is familiar. This will be an incremental exercise. I hope I can customize WordPress enough to make for a seamless look. Short-term, I’m sure it’ll be a bit rough. Tips and suggestions welcome.

Atom