Skip to content
Search

Unit testing

lastmod 2025-12-08created 2020-09-2812 edits

A unit test is a procedure in computer programming that verifies whether a specific module of source code works exactly as intended. In other words, it is the process of writing test cases for every function and method. This makes it possible to quickly identify and fix problems whenever a code change causes them. Ideally, each test case should be isolated from the others. Creating mock objects is a good way to achieve this. Unlike general testing, unit tests are performed not only by developers but sometimes also by testers for more in-depth testing.

Categories

Terms

Spy
Records whether a function was called, and records its return value, arguments, and so on each time it runs (typically used for tests like "Did this action call the function I wanted?")
Stubbing
Spying on a function while overriding its logic can be called stubbing (mainly used in unit tests to reduce side effects caused by a component's dependencies)
Mock
Like stubbing, it can replace a function's implementation or change the function's return value as desired
Assertion
A feature that checks "Am I getting the result I want?". Assertion libraries provide utility functions for comparing variables (objects, arrays, strings, numbers) easily and readably
Snapshot
The test records to a file what output a component produces when it renders. If the rendered output changes after a code change, the test fails (typically used to prevent situations like "I only changed the logic, so why did the DOM change?")
Instrumentation
To calculate test code coverage, every file must be wrapped to measure how many lines of the whole codebase are executed and how many times each line runs. This process is called code intrumentation. It is usually wrapped with the istanbul library in the babel configuration (Caution: never use instrumentation in a production environment!!)
Korean: 디바운싱 (Debouncing)
Making only the last (or the first) of a series of consecutive function calls actually run
Korean: 쓰로틀링 (Throttling)
Controlling an event handler so that it runs only once within a given period of time

given-when-then pattern

These days, unit tests are mostly written with the given-when-then pattern. The given-when-then pattern splits a single unit test into three stages, each meaning the following.

  • given (arrange): When (given) some data is prepared.
  • when (act): (When) some function is executed.
  • then (assert): (Then) some result should come out. 
@DisplayName("로또 번호 갯수 테스트")
@Test
void lottoNumberSizeTest() {
    // given

    // when

    // then
}

FIRST (5 properties of good tests)

5 properties of good tests

Fast
Tests should run fast.
Slow tests slow down work on improving code, which can lower code quality.
It helps to write unit tests with a simple purpose or ones that do not use the external environment.
Isolated - independent
A single piece of test code should target only one subject.
If a test interacts with other test code or uses external sources that cannot be controlled, the test case may later fail due to external factors.
Repeatable
Tests should be written so that they can be repeated in any environment.
Self-Validating
A test should complete its own verification by itself.
You should write code that can confirm whether the test passed or failed, for example through assert methods.
If a developer has to check results by eye after writing test code, it is poor test code.
Timely
Test code should be completed before implementing the application code it tests.
Test code written too late may not serve its proper role.
It can also increase the development cost of fixing problems found by the test code.
In short, write test code ahead of time.
However, this concept matters only for TDD (test-driven development); otherwise this rule can be skipped.

See also

Favorite site

author Zer0 sitemap