Is "sut" a good variable name?

During a review of one of my pull requests a short discussion about me using sut started. The reviewer opposed it, while I think it is a good idea. I started to list some arguments for and against this habitus. Naturally, I also looked online for supporting arguments to back up my opinion. There was not much input to be found on this, which gave me the idea for this article—I also asked some more people for their opinion and incorporated their answers.

NOTE

In case the term sut is new to you: it stands for ‘system under test’. It is not uncommon to use sut as variable name for the instance of the class that is being tested.

The naming of variables

Software developers have few discussions as passionate as the naming of variables. This article is about one particular variable: the one that holds the instance/reference of the class that is being tested. The question is whether it is a good idea to name it sut or uut or something like that? For better readability, let’s stick to using sut as example.

This is a quite philosophical discussion, which is better done having a glass of wine and some cheese. Let’s try to find out whether sut is a good variable name, without wine nor cheese.

My reasons for considering “sut” a good variable name

To make it short, here are the reasons, why using sut is a good thing. They are in no specific order, completeness is not guaranteed.

It is brief

Only few variable names are three characters or fewer. In object-oriented programming it is not uncommon to have lengthy class names. Some made up, but not unrealistic examples are

• ThirdpartyPaymentResponseAssembler
• OutboundTransactionDetailsController
• CustomerAccountCreationController

It gives additional context

Reading sut immediately makes it clear the code is part of a test, without knowing the rest of the class. True, a variable named sut does not reveal, what kind of system/class is being tested. However, the reader usually knows which class the code he is reading comes from. A very common argument is that it is not clear what sut is. I disagree: besides the class name, the instantiation of sut already reveals what is being tested:

val thirdpartyPaymentResponseAssembler = ThirdpartyPaymentResponseAssembler()

tells the reader less than:

val sut = ThirdpartyPaymentResponseAssembler()

It is easy to see that the term ThirdpartyPaymentResponseAssembler is duplicated in the first example. The use of sut on the other side adds information.

It adds structure

sut implicitly adds structure to the test, by highlighting the location of the ‘Act’ (regarding the AAA-pattern).

// Arrange
redCar.passengers = listOf(Person("John"), Person("Jane"))
blueCar.passengers = listOf(Person("Henry"))
val allCars = listOf(redCar, blueCar)

// Act
val greetings = sut.greetAllPassengers(allCars)

// Assert
assertThat(greetings)
    .containsExactlyInAnyOrder("Hello, Jane!", "Hello, John!", "Hello, Henry!")

Reasons against using “sut”

It does not reveal what is ‘under test’

Having claimed that the reader usually knows which class the code he is reading comes from, I must admit, it is true that there is a trade-off sut.calculate(date) is not as suggestive as dateCalculator.calculate(date). Some of this can be mitigated by using expressive method names.sut.calculateHoursUntilToday(date) would be expressive enough if used instead of dateCalculator.calculateHoursUntilToday(date).

Until about a year ago, I used to have a different opinion about sut. It changed, when I was facing a quite complex setup and business logic I was not fully understanding, because I still was new to the project.

The naming convention must be generally accepted.

The headline speaks for itself. If parts of the team are against sut as acceptable name, there is no point in enforcing it. It is better to agree on another variable name or naming convention.

Say No to dogmatism!

Let’s not be dogmatic here. Of course, the readability of short tests with few lines of code or low complexity, do not profit from using sut. Poorly written code does not become straightforward magically, by using sut as variable name! Doing many little things to improve readability adds up, however.

Also, it does not help to use sut, if it is not accepted by other team members. This would lead to a cocktail of both variants. If there is a common agreement on another term than sut (i.e., objectUnderTest or objectToBeTested) then that is fine, too. Except for the shortness of the name the other advantages persist.

In most cases it is recommendable to document what term to use, especially for new members of the team. Otherwise, you might stumble over something like tf, the meaning of which only the original author knows about.

Lastly, I have to confess: in most cases in which I am using sut, I should actually be using uut (unit under test). Because it is commonly accepted, we stick to it. The benefit of changing this single letter does not justify the hassle. Sometimes it is better to be consistent than correct, isn’t it?