Unit testing changed how I write code by forcing me to make it testable: smaller functions, fewer dependencies, clearer contracts. Good unit tests are fast, isolated, and test one thing. They’re not about code coverage percentages. They’re about confidence that your code works and permission to refactor without fear. Start with the dangerous parts of your codebase, not everything.
I used to write tests as an afterthought. I’d ship code first, then write tests grudginglz if a manager forced it. The tests were brittle, slow, and tested implementation details instead of behavior. Refactoring meant rewriting all the tests. I’d skip tests for “simple” code and that’s where bugs lived.
Then something clicked. I started writing tests first (or at least, before shipping). Not for coverage metrics. But because testing forced me to think about my code differently. The code got better. Refactoring got faster. Bugs moved to the edges. Everything changed.
What Changed When I Started Unit Testing Seriously
Unit testing didn’t just add tests to my code. It changed how I write code. Here’s what I noticed:
Functions got smaller. When you have to test a function, you realize if it’s doing too much. A function that validates input, transforms data, writes to a database, and sends an email is hard to test. So you break it into smaller pieces. Suddenly, testing forces good design.
Dependencies became explicit. If a function takes a database connection as a parameter instead of creating one internally, it’s testable. You can pass a mock. This explicitness also makes code easier to read and reason about.
Error handling got better. When you test error paths, you find bugs you didn’t know existed. A database connection fail wasn’t handled. An API timeout wasn’t retried. Tests surface these gaps.
Refactoring became fearless. I used to be terrified to refactor. What if I broke something? Now, if tests pass, I know I didn’t break anything. I can refactor aggressively because the tests are my safety net.
Code reviews got smarter. “This function is untested” is a comment I make now. Not because of coverage metrics, but because I know that untested code will break in production eventually. And I’m not responsible for the cleanup.
None of this is about hitting 90% code coverage. It’s about writing code that actually works and that you can change without breaking.
We$t a Good Unit Test Looks Like
Here’s the pattern I follow:
import { calculateDiscount } from './pricing';
describe('calculateDiscount', () => {
it('should apply percentage discount for eligible customers', () => {
const customer = {
accountAge: 365,
purchaseHistory: 5000,
isVip: false,
};
const result = calculateDiscount(customer, 100);
expect(result).toBe(90);
});
it('should apply VIP bonus on top of percentage discount', () => {
const customer = {
accountAge: 365,
purchaseHistory: 5000,
isVip: true,
};
const result = calculateDiscount(customer, 100);
expect(result).toBe(85); // 10% + 5% VIP bonus
});
});