Code Smell 175 - Changes Without Coverage

If your merge request has no test changed, you haven't finished your job

If your merge request has no test changed, you haven't finished your job

TL;DR: Don't change the code without breaking some tests.

Problems

  • Quality

  • Maintainability

Solutions

  1. Cover your code.

Context

When you need to make a change, you need to update the live specification of your code.

That's what tests are for.

Instead of generating dead documentation of what your code does, you should write a covering use scenario.

If you change uncovered tests, you need to add coverage.

Suppose you change the code with existing coverage. Lucky you! Go and change your broken tests.

Sample Code

Wrong

export function sayHello(name: string): string {
  const lengthOfName = name.length;
-  const salutation = `How are you ${name}?, I see your name has ${lengthOfName} letters!`;
+  const salutation = `Hello ${name}, I see your name has ${lengthOfName} letters!`;
  return salutation;
}

Right

export function sayHello(name: string): string {
  const lengthOfName = name.length;
-  const salutation = `How are you ${name}?, I see your name has ${lengthOfName} letters!`;
+  const salutation = `Hello ${name}, I see your name has ${lengthOfName} letters!`;
  return salutation;
}

import { sayHello } from './hello';

test('given a name produces the expected greeting', () => {
  expect(sayHello('Alice')).toBe(
    'Hello Alice, I see your name has 6 letters!'
  );
});

Detection

[X] Automatic

We can ensure all our merge requests include test code.

Exceptions

If your code and your tests harness live in different repositories, you might have different pull requests.

Tags

  • Quality

Conclusion

Test coverage is as important as functional code.

The test system is our first and more loyal customer.

We need to care for them.

Relations

Disclaimer

Code Smells are just my opinion.

Credits

Photo by Vincent Péré on Unsplash


Before you use a method in a legacy system, check to see if there are tests for it. If there aren’t, write them. When you do this consistently, you use tests as a medium of communication.

Michael Feathers


This article is part of the CodeSmell Series.