Category Archives: Software Development

Don’t comment out your tests, there are better alternatives!

You’ve either done it yourself or you’ve seen others done it. Uncommented a whole test, a test fixture or maybe an entire file.

I know, it’s so easy to press Ctrl+A, Ctrl+K+C to uncomment everything. You’re probably changing an interface. Most likely, the methods that are tested don’t exist anymore in the form in which the tests calls them. You probably just click and drag the mouse and comment out a block. But please, be careful. I’ve seen a lot of examples where an entire file ended up commented out for months. Only to turn out to be crucial, because it tested a very important scenario.

First and foremost, if you are refactoring, please look at the tests as if it’s production code. You are best off getting the tests to compile, even if that takes extra time and you’d rather pull the main code back on its feet before you worry about the tests. Be aware that the “it takes extra time…” is a fallacy. It just takes time. It’s part of your job. It’s not less important than the rest of the code. Probably the contrary. You’re better off keeping the tests compiling all the time.

But if you must, please, don’t comment out a whole test or whole fixture. If you must, then do it like this, instead:

    public void SomeMethod_SomeCondition_ShouldDoSomething()
        // Arrange
        // SystemUnderTest sut = new SystemUnderTest();
        // sut.SetupSomeData();

        // Act
        // sut.DoesNotCompile();

        // Assert
        // Assert.IsTrue(sut.SomePredicateDoesNotCompile());
        Assert.Fail("TODO: Fix this test");

That way, at least your test suite will alert you that there are a couple of tests you still need to fix. And you won’t have a colleague pointing out to you that that commit you did two months ago effectively deleted some really important tests…

Time travel and parallel universes

Suppose you’re working on a software project and you’ve tagged your release 0.1.0. It has been shipped and now you’re working on version 1.0.0. You’re reworking quite a lot. It’s a major release after all, a lot to be done 🙂

In comes someone who sees version 0.1.0 and thinks to him/herself: “Oooh, can you maybe add some functionality on top of that? I don’t want to wait for 1.0.0, that takes too long.”

Although the ‘building a house’ metaphor is a strained one when it comes to software, it can be used to abstract away from the nitty gritty detail of software development and describe things like project management and development strategies. Today, let’s discover some of the superpowers we have in software-land, and what their limitations are. And let’s use our superpowers to build a house 😉

Version control, especially Git, grants you the powers to:

  • work in parallel universes (branch)
  • go back in time (branch from older release or commit in the past)
  • automatically replay anything you did in a parallel universe in another parallel universe (merge or rebase)

This is convenient when we’re doing things that are unrelated. Two developers could branch from trunk (or master or main stream) and work in their own branches quite comfortably, as long as they don’t do conflicting things in the code base. Or, to strain the house metaphor to its breaking point: Someone could be installing a new kitchen while another team replaces the roof.

Continue reading