Wednesday, August 27, 2008

When True does not equal True

One of my colleagues came across an interesting bug today. He was running this test:

   1:  [Test]
   2:  public void DoMXLookupWithValidDomainName()
   3:  {
   4:      MXLookupHelper mxHelper = new MXLookupHelper();
   5:      mxHelper.DomainName = "google.com";
   6:      bool validDomain = mxHelper.hasMxRecord();
   7:      Assert.IsTrue(validDomain);
   8:  }

The test was failing with the rather unhelpful message:

Expected True, but was True.

It's not everyday that you see a boolean value of True not equalling True, so he called me over to have a look, we must have had half the office trying to figure that one out.

Our immediate solution was simple enough - modify the method hasMxRecord() so that the last line reads:

return foundRecord ? true : false;

which is something that sets afire every refactoring nerve in my body, so I had to add a huge comment to that line, to the effect that, "Yes I know it looks pointless, but you'll just have to trust me, it is there for a reason".

We were able to reproduce the effect on another colleague's machine, but of course when I tried it on my machine, the test worked as expected. The only difference that we could tell was the version of the .NET Framework that we were running, mine reporting 2.0.50727.3053, while theirs were reporting 2.0.50727.1433, so it may be a bug in the .NET Framework v2.0 which has been finally fixed with the release of .NET Framework v3.5 Service Pack 1, which I installed last week.

Of course, this incident just reminded of the frequent stories of people's flagrant abuse of simple boolean logic on The Daily WTF.

UPDATE: this appears to be part of a very old bug. Not bad, only taking three years to fix...

No comments: