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.
-
Quality
-
Maintainability
- Cover your code.
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.
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;
}
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!'
);
});
[X] Automatic
We can ensure all our merge requests include test code.
If your code and your tests harness live in different repositories, you might have different pull requests.
- Quality
Test coverage is as important as functional code.
The test system is our first and more loyal customer.
We need to care for them.
Code Smell 05 - Comment Abusers
Code Smells are just my opinion.
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
Software Engineering Great Quotes
This article is part of the CodeSmell Series.