“When am I supposed to write all this…?” Even building one feature is a rush, so being asked to write tests too can honestly make you sigh.
The short answer: the real reason to write tests is to protect your future self. You spend 10 extra minutes now to prevent an outage from erupting at 3 a.m. three months later.
Why Write Test Code?
The biggest reason is that fixing code no longer feels frightening.
Code is never truly finished after you write it once. You keep changing it and adding features.
Without tests, every one-line change makes you uneasy. “If I fix this, will something break somewhere else?”
With tests, you can verify the change with a single run. Green means relief; red immediately shows what broke.
This is called regression testing: it catches things that worked before but have broken again.
The Real Reason to Write Tests Despite the Hassle
Honestly, tests feel like a loss at first. They do not add a visible feature, after all.
But the story changes as the project grows.
Once you have 30 or 50 features, checking everything by hand is impossible. You cannot click through the entire app every time you change one thing.
With tests, you can verify dozens of cases in seconds with a single command.
The second reason is that test code becomes documentation.
Well-written tests make it immediately clear what results a function produces for particular inputs.
Comments can lie when they become outdated, but tests run, so they cannot lie.
Here is a simple example: a test for a function that calculates a discount.
// 1ten-thousand-won purchase 10% discount → 9should be one thousand won
@Test func apply the_10discount_percentage() {
let result = applyDiscount(10000, rate: 0.1)
#expect(result == 9000)
}Even from this test alone, you can immediately understand what applyDiscount does.
How Do You Start Writing Tests?
Trying to test everything from the start will exhaust you and make you give up.
I recommend starting like this.
- Start with core logic where failure would be serious, such as money calculations and login
- Functions with many conditional branches that are easy to get confused by
- Places where a bug has occurred before, for regression prevention
Conversely, simple UI code and frequently changing areas can wait.
The goal is not 100% coverage of everything; what matters is weighing the payoff against the cost.
Frequently Asked Questions
Q. Does writing tests slow development down?
A. It does at first. But from the middle of a project onward, it actually makes development faster because the time spent finding and fixing bugs drops sharply.
Q. What test coverage percentage is best?
A. There is no need to obsess over the number. 70–80% is enough; what matters more is whether the important logic is covered.
Test code is not a way to show off your skills; it is a safety net for your future self and your teammates.
Add just one test to one function you wrote today. Once you feel the relief of that small green light, you will understand firsthand why everyone tells you to write tests.