Ruthlessly Helpful

Stephen Ritchie's offerings of ruthlessly helpful .NET practices.

Don’t Comment Out Failing Unit Tests

While working with a rather large Brownfield codebase I came upon a set of commented out unit tests. I uncommented one of these unit tests and ran it.

Sanitized illustrative code sample:

[Test]
public void ProductionSettings_BaseBusinessServicesUrl_ReturnsExpectedString()
{
    // Arrange
    var settings = new ProductionSettings();

    // Act
    var actual = settings.BaseBusinessServicesUrl;

    // Assert
    Assert.AreEqual("http://localhost:4321/Business.Services", actual);
}

As expected, the test failed. Here’s some pseudo-output from that test:

SettingsTests.ProductionSettings_BaseBusinessServicesUrl_ReturnsExpectedString : Failed

NUnit.Sdk.EqualException: Assert.AreEqual() Failure
Position: First difference is at position 17
Expected: http://localhost:4321/Business.Services
Actual:   http://localhost:1234/Business.Services

at Tests.Unit.Acme.Web.Mvc.Settings.SettingsTests
    .ProductionSettings_BaseBusinessServicesUrl_ReturnsExpectedString()
in TestSettings.cs: line 19

So now what should I do? That output prompts the question: what’s the correct port? Is it 1234, 4321 or is it some other port number? To sort this all out I’ll need to take on the responsibility of researching the right answer.

Almost certainly, Mr. or Ms. Comment-out-er gave me this chore because he/she did not have the time to sort it all out themselves. Also, likely, the person who changed the port number didn’t know there was a unit test failing or even that there was a unit test at all. I don’t need to know who did or didn’t deal with this; I’ll leave that to the archeologists.

The larger point is this: if you’re commenting out a failing unit test then you’re missing the point of a unit test. A unit test verifies that the code-under-test is working as intended. A failing test means you need to do something — other than commenting out the test.

If a unit test fails then there are four basic options:

  1. The code under test is working as intended; fix the unit test.
  2. The code under test is NOT working as intended; fix the code.
  3. The code under test has changed in some fundamental way that means the unit test is no longer valid; remove the unit test code.
  4. Set the unit test to be ignored (it shouldn’t fall through the cracks now), report it by writing up a “fix failing unit test” defect in the bug tracking system, and assign it to the proper person.

Commenting out a unit test means that you’re allowing something important to fall through the cracks. The big no-no here is the commenting out. At the very least, pick option 4.

Advertisements

One response to “Don’t Comment Out Failing Unit Tests

  1. Jeff Gallimore May 27, 2011 at 10:29 am

    I like the simplicity of your checklist. Simplicity is powerful. Now it’s effectiveness will rest in 1) educating developers on the “proper” way to handle a failing unit test, and 2) ensuring they maintain the discipline to do it the “proper” way.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: