Unnecessary Unit Tests

Hi,

Ever Heard of Tautological Tests?

In recent months, I’ve delved back into test architecture and design.

(I can’t quite remember how it all started… probably the YouTube algorithm suggesting interesting talks again 😉)

Anyway, I wrote back in early December that a few years ago, in a blog, I propagated practices quite different from what I recommend today.

The topic keeps gripping me, so today, it’s about tests again.

tautological adjective

“using two words or phrases that express the same meaning, in a way that is unnecessary and usually unintentional”

A Tautological Test Mirrors the Implementation - Just in Different Words

I keep coming across such tests. Honestly, I’ve written them myself for far too long without realizing how pointless they are.

But let’s look at an example:

Suppose we have a method that does the following:

public void createOrder(UUID customerId, String orderName) {
  Customer customer = customerRepository.findById(customerId);
  Order order = orderFactory.createOrder(orderName, customer);
  orderRepository.save(order);
}

And the corresponding test looks like this:

@Test
public void createOrderSavesTheOrder() {
  Customer customer = new Customer("customerName");
  String orderName = "orderName";
  Order order = new Order(orderName, customer);

  when(orderFactory.createOrder(orderName, customer)).thenReturn(order);
  when(customerRepository.findById(customer.getId())).thenReturn(customer);

  orderService.createOrder(customer.getId(), orderName);

  verify(orderRepository).save(order);
}

Then we see a classic tautological test.

In the test, we’re just rephrasing the implementation.

when(orderFactory.createOrder(orderName, customer)).thenReturn(order); is the same statement as Order order = orderFactory.createOrder(orderName, customer); in the implementation.

Such a Test is Not Only Meaningless - It Degrades Code Maintainability

A tautological test like this makes it annoying for developers to refactor the implementation.

Any change in the code (Yes, any!) results in having to adjust the test. And this doesn’t even require a semantic change.

The test adds no value. It’s just in the way.

Honestly: Such tests can be deleted right away. Focus on functionality, not implementation. You need to write tests that test very specific (!) results. Your implementation should be independent of this.

Writing good tests requires practice and training. Have you ever hosted a coding dojo and practiced TDD? Have you done it with your team?

Give it a try. And if you need help with it, just get in touch with me!

Rule the Backend,

~ Marcus