Unit Testing
Unit Testing
What is unit testing?
- Automatically verify small pieces of code
- Confirm a fix didn't break anything
- Improve quickly, with confidence
What unit tests really change is not the code but how the team makes decisions. In a codebase without tests, improvement proposals keep getting shelved in meetings because 'we don’t know what will break if we touch that function.' So instead of removing outdated logic, people pile on one more conditional to work around it, and the file keeps growing every year. With tests in place, the standard shifts to 'just fix it and run the tests.' Even if a developer three months into the job touches a five-year-old payment module, a test that runs in seconds will flag any problem, and the change can be reverted on the spot.
In practice, tests are used in layers. A unit test isolates a single function and runs in milliseconds, without touching a database, external API, or file system. Once a database connection or API call is involved, it becomes an integration test; once a browser is launched to follow a user scenario, it is an E2E test. External dependencies are replaced with fake objects (mocks and stubs) to keep tests fast and reproducible. The usual structure is a thick base of fast, frequently run unit tests, with a thin top layer of slow E2E tests. For coverage, start with modules where money is at stake, such as payments and settlement. Where coverage lands matters far more than the overall average.
Things usually go wrong in three places. First, if you set 80% coverage as a KPI, you get more tests that call functions without any assertions just to fill the number. The metric stays green while incident counts stay the same. Second, tests tied to internal implementation. If they verify call order or even internal variables, dozens break with every refactor, and developers comment them out instead of fixing them. Third, a broken test left unfixed for more than a day is a dead test. Once a red build becomes routine, nobody looks at it. Also, unit tests do not replace QA or acceptance testing: every part can work fine and the assembly can still be wrong.
Jaryong KooMarketing PhD and authority in AI, data analytics, and personal branding
John KimAuthor of B2B Marketing Design and CEO of Nanum ConsultingA verification technique in software engineering that became standard practice alongside the spread of test-driven development (TDD) and automation tools.
Consider a hypothetical case: the development team at Company A, which runs a logistics SaaS with 240 employees. Each of its two regular monthly releases averaged three incidents, forcing repeated overnight rollbacks, and nobody wanted to touch the six-year-old settlement module. Tests existed, but overall coverage was only 8%.
- When Manager Kim, the development team lead, sorted the past year’s 47 incidents by module, half came from just two places: settlement and fee calculation. The team narrowed its scope to 'Don’t try to cover everything. Start here.'
- For the fee calculation function, the team turned the contents of real incident tickets directly into tests. They wrote 32 cases over two weeks, covering late-night surcharges, remote-island surcharges, return fees, and more.
- Calls to the external shipping carrier API were replaced with mock objects, cutting total run time from 11 minutes to 40 seconds, and the tests were set to run automatically in CI on every commit.
- After the build stayed broken for two days, Manager Kim made 'nobody goes home on a red build' a team rule, and the average time to fix a broken test dropped to under half a day.
- Six months later, coverage of the two modules reached 76%, incidents per release fell from 3 to 0.5, and overnight rollbacks dropped from 4 per quarter to 0. Improvements to the long-postponed settlement module were back on the schedule for the first time in three years.