Skip to content

Unit testing

유닛 테스트(unit test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 (일반적인 테스트와 달리) 개발자(developer) 뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터(tester)에 의해 수행되기도 한다.

Categories

Terms

Spy
어떤 함수를 실행 여부 기록하고, 함수 실행할 때마다 그의 응답 값, Argument 등을 기록해 줍니다 (보통 “이 액션을 통해서 내가 원하는 함수가 실행됐을까?” 성격의 테스트를 할 수 있습니다)
Stubbing
어떤 함수를 스파이하면서, 그 함수의 로직을 오버라이딩 시킬때 stubbing이라고 볼 수 있습니다 (보통 어떤 컴포넌트의 의존성으로 인한 사이드 이펙트의 양을 줄이기 위해 단위 테스트에 주로 사용됩니다)
Mock
Stubbing과 같이 어떤 함수의 implementation을 대체하거나, 그 함수가 응답 값이 원하는대로 변경할 수 있습니다
Assertion
“내가 원하는 결과를 받고 있을까?” 확인해 주는 기능인데요. Assertion 라이브러리들은 변수 (객체, 배열, string, number)가 쉽고 가득성 좋게 비교할 수 있는 utility 함수들을 제공해 줍니다
Snapshot
테스트는 어떤 컴포넌트가 렌더링될 때, 어떤 아웃풋이 나오는지 파일로 기록해 줍니다. 만약에 코드 수정 후에 렌더링되는 아웃풋이 변경되면 테스트가 실패하게 됩니다 (보통 “내가 로직만 수정했는데 DOM이 왜 바뀌는거지?”라는 상황을 예방하기 위해 사용합니다)
Instrumentation
테스트 코드 커버리지를 계산하려고 내 코드베이스 전체 라인에서 몇줄이 실행 되는지, 각 라인에서 몇번 실행되는지 측정하기 위해서 모든 파일을 wrapping해야 합니다. 이 과정이 code intrumentation이라고 합니다. 보통 babel 설정에서 istanbul 라이브러리로 wrapping합니다 (주의: production 환경에 instrumentation을 절대 쓰지 마세요!!)

given-when-then 패턴

요즘 단위테스트는 거의 given-when-then 패턴으로 작성하는 추세이다. given-when-then 패턴이란 1개의 단위 테스트를 3가지 단계로 나누어 처리하는 패턴으로, 각각의 단계는 다음을 의미한다.

  • given (준비): (주어진) 어떠한 데이터가 준비되었을 때.
  • when (실행): (언제) 어떠한 함수를 실행하면.
  • then (검증): (그다음) 어떠한 결과가 나와야 한다. 
@DisplayName("로또 번호 갯수 테스트")
@Test
void lottoNumberSizeTest() {
    // given

    // when

    // then
}

FIRST (좋은 테스트를 작성하는 5가지 속성)

좋은 테스트를 작성하는 5가지 속성

Fast - 빠르게
테스트는 빠르게 수행되어야 한다.
테스트가 느리면 코드를 개선하는 작업이느려져 코드 품질이 떨어질 수 있다.
목적을 단순하게 설정해서 작성하거나, 외부 환경을 사용하지 않는 단위 테스트를 작성하면 좋다.
Isolated - 고립된, 독립적
하나의 테스트코드는 하나의 대상에 대해서만 수행되어야 한다.
만약 하나의 테스트가 다른 테스트 코드와 상호작용하거나 관리할 수 없는 외부 소스를 사용하게 되면 이후 외부 요인으로 인해 테스트케이스가 실패할 수도 있다.
Repeatable - 반복 가능한
테스트는 어떤 환경에서도 반복 가능하도록 작성해야 한다.
Self-Validating - 자가 검증
테스트는 그 자체만으로 테스트의 검증이 완료되어야한다.
assert 메서드 등을 통해 테스트가 성공했는지 실패했는지 확인할 수 있는 코드를 작성해야 한다.
만약 개발자가 테스트 코드 작성 후 눈으로 확인해야한다면 좋지 못한 테스트코드이다.
Timely - 적시에
테스트코드는 테스트하려는 애플리케이션 코드를 구현하기 전에 완성되어야 한다.
너무 늦게 작성된 테스트코드는 정상적인 역할을 수행하지 못할 수 있다.
또한 테스트 코드로 인해 발견된 문제를 해결하기 위해 소모되는 개발 비용이 커질 수 있다.
즉 미리미리 테스트코드를 짜야한다.
다만 이 개념은 TDD(테스트 주도 개발)시에만 중요하고, 이외에는 이 규칙은 생략하고 진행할 수도 있다.

See also

Favorite site