Naming SUT Test Variables

If you are a regular reader of this blog, you may have noticed that for the last couple of months, every test I've posted has shared some similarities; one of which is that I always name my SUT test variable sut. Here's a simple example:

[TestMethod]
public void DoStuffWillReturnMessage()
{
    // Fixture setup
    string expectedResult = "ploeh";
    MyClass sut = new MyClass();

    // Exercise system
    string result = sut.DoStuff(expectedResult);

    // Verify outcome
    Assert.AreEqual<string>(expectedResult, result, "DoStuff");

    // Teardown
}

Notice how the new instance of MyClass is named sut, and not, say, mc.

No matter the name of the class, I always name the variable sut, since it gives me at least two advantages:

1. It Very Clearly Identifies the SUT

In the above example, it may be very apparent that the SUT is an instance of MyClass no matter the name of the variable. However, as test complexity grows, the sut variable may disappear among other variables, as this example illustrates:

[TestMethod]
public void ComplexOperationWillSucceed()
{
    // Fixture setup
    string expectedBar = "bar";
 
    Fnaah f = new Fnaah();
    Ndøh n = new Ndøh(f);

    MyClass sut = new MyClass();

    // Exercise system
    Foo result = sut.ComplexOperation(n);

    // Verify outcome
    Assert.AreEqual<string>(expectedBar, result.Bar, "ComplexOperation");

    // Teardown
}

Had the SUT variable been mc, it would have been much less apparent which of f, n, or mc was the actual SUT, and which variables just belonged to the Test Fixture. Although the rest of the Four-Phase Test structure (including the comments) helps the Test Reader in figuring out which of the variables is the SUT, the name of the variable is definitely a helpful hint.

2. It Is Robust Against Refactoring

Imagine that instead of sut I had named the MyClass variable mc in all my 200 tests, and that I then decided to rename MyClass to ØhmHvadVedJeg (note to self: Use Danish characters in class names more often!). In that case, I would now have 200 tests where instances of ØhmHvadVedJeg were called mc. That's not very nice to the poor Test Reader.

You could of course manually edit all 200 tests to align the variable names again, but that's a bit of work, and you may even forget that you have to do that, since the renaming probably took place somewhere completely different.

When the SUT variable name is sut, you can rename your types as much as you want; the tests will still be communicative and correct.

Comments

• Anonymous
  October 07, 2008
  Interesting .. I never really thought about doing that. Going to give it a shot :)

• Anonymous
  October 08, 2008
  Cool! At first it feels a little weird, so give it time to grow on you :)

• Anonymous
  October 22, 2008
  Makes sense. In the past I have repeatedly gone through the exercise of renaming my test variables until I finally settle on a descriptive name. SUT might just cut it.

• Anonymous
  November 12, 2008
  Writing good code is difficult. Unit tests are written as code, so a corollary to the first sentence

• Anonymous
  November 20, 2008
  This is an installment in my Zero-Friction TDD series. Sometimes, you don't care about the return value

• Anonymous
  July 24, 2012
  good, but as a personal preference and holding only the personal value, I try to be a bit clearer and use sutSomeClass