JavaScript 테스트 모범 사례

황금률: 린(lean)한 테스트

테스트 코드는 제품 코드와 다르다. 단순하고 짧고 추상화 없이, 보자마자 의미를 알 수 있게 쓴다. 제품 코드를 붙잡고 있는 머리에 또 하나의 어려운 코드를 얹으면 팀이 느려지고, 결국 테스트를 버린다. 테스트는 수학 문제가 아니라 HTML을 고치듯 가볍게 읽혀야 한다.

그래서 모든 것을 테스트하지 않는다. 비용 대비 효과(ROI)가 큰 대상과 기법만 골라 쓰고, 단순함을 위해 일부 신뢰도를 포기하는 것도 정당하다. 아래 원칙은 대부분 이 황금률에서 나온다.

테스트 하나를 쓰는 법

1. 이름에 세 가지를 담고, 두 단계 이상으로 묶는다

무엇을(대상), 어떤 상황에서(시나리오), 무엇을 기대하는지(결과). 실패한 테스트 이름만 읽고도 무엇이 깨졌는지 알 수 있어야 한다. 테스트 보고서는 코드를 모르는 사람(QA, 배포 담당, 2년 뒤의 나)도 읽는다.

describe('주문 서비스', () => {          // 대상
  describe('가격이 없을 때', () => {     // 상황
    test('상태 400을 돌려준다', async () => { /* ... */ })   // 기대
  })
})

describe를 최소 두 단계(대상 → 상황)로 두면 보고서가 계층으로 묶인다. 100개 중 7개가 실패해도 같은 상황 아래 모여 있으면 원인 자리가 바로 보인다. 대상·상황·행동 계층(Describe-Context-It)은 백엔드 테스트에, given-when-then 같은 다른 구조도 같은 목적이다.

2. AAA로 나누고, 단언은 제품의 언어로

준비(Arrange) → 실행(Act) → 검증(Assert)을 빈 줄로 나눈다. 실행과 검증은 대개 한 줄이다. 검증은 반복문·조건문 대신 선언적인 단언으로 쓴다. expect(admins).not.toContain(user)처럼 읽히는 BDD 스타일이면 QA·기획자도 읽는다. 같은 검증이 자주 반복되면 커스텀 매처(expect.extend)로 만든다.

3. 블랙박스로 테스트한다

공개된 동작과 결과만 검증한다. 공개 동작을 검증하면 내부 구현도 함께 검증된다. 내부 메서드·상태를 직접 확인하면 동작이 같아도 리팩터링할 때마다 깨지는 거짓 양성이 생기고, 경보가 잦아지면 팀은 CI 실패를 무시하기 시작한다. 컴포넌트의 행위 중심 검증은 프론트엔드 테스트의 종류와 도구에 있다.

4. 테스트 대역은 요구사항 기준으로 고른다

대역을 쓰기 전에 묻는다. "이 대역으로 확인하려는 것이 요구사항(외부로 보이는 결과)인가, 내부 구현인가?"

대역의 종류와 고르는 기준(명령-조회 분리)은 프론트엔드 테스트의 종류와 도구에, 목을 줄이는 설계는 험블 객체 패턴에 있다.

5. 데이터: 현실적으로, 다양하게, 필요한 것만 드러나게

세 번째 원칙을 어기면 미스터리 게스트(mystery guest)가 생긴다. 보이지 않는 데이터가 결과를 정해서, 테스트를 읽어도 왜 그 결과가 기대되는지 알 수 없다.

// 왜 409인지 테스트만 읽고 안다
const request = factorTransfer({ userCredit: 100, transferAmount: 200 })
const response = await new TransferService({ disallowOvercharge: true }).transfer(request)
expect(response.status).toBe(409)

프로퍼티 기반 테스트는 이렇게 쓴다.

import fc from 'fast-check'
 
test('어떤 상품이든 추가하면 장바구니 개수가 1 늘어난다', () => {
  fc.assert(fc.property(fc.string(), fc.integer({ min: 1 }), (name, price) => {
    const cart = new Cart()
    cart.add({ name, price })
    expect(cart.count).toBe(1)
  }))
})

6. 그 밖의 원칙

프런트엔드와 E2E

백엔드

테스트 종류를 위험에 맞춰 고른다

단위 테스트와 피라미드에만 머물지 않는다. 로직이 거의 없고 메시지 큐·DB를 잇는 통합 중심 서비스라면 단위 테스트에 예산을 몰 이유가 없다. 「API가 자주 깨진다 → 계약 테스트」처럼 실제 위험에서 출발해 단위·컴포넌트·계약·E2E·성능·보안·퍼즈·뮤테이션을 포트폴리오처럼 섞는다. 전략의 모양(피라미드·트로피·벌집)은 테스트의 종류에 있다.

컴포넌트 테스트: 서비스 하나를 바깥에서

단위보다 크고 E2E보다 작은 컴포넌트 테스트가 가장 효율적일 때가 많다.

가로채기의 진짜 가치는 시나리오를 만들 수 있다는 데 있다. 공급자가 주는 Docker 가짜 서버나 샌드박스 환경은 설정은 쉽지만 원하는 응답을 골라 낼 수 없다. 반대로 가로채기는 상대 서비스가 바뀐 것을 알지 못하므로 계약 테스트나 소수의 E2E로 보완한다.

행복·불행 경로 너머: 통합 지점의 장애

오류 응답(500)만이 아니라 네트워크 수준 이상까지 흉내 낸다.

nock은 .delay()·.replyWithError(), MSW는 delay()·HttpResponse.error()로 만든다. 지켜야 할 패턴 자체는 복원력 패턴에 있다.

검증할 결과 다섯 가지

동작 하나(API 호출 등)를 일으킨 뒤, 바깥에서 보이는 결과를 다섯 범주로 점검한다. 어떻게 동작했는지가 아니라 무엇이 일어났는지를 본다.

ID·생성 시각처럼 미리 알 수 없는 값은 존재와 타입을 단언한다. 계약이 그 필드를 약속했다면 빠지는 것도 버그다. 응답 전체를 OpenAPI 문서와 대조하는 검증도 같은 목적이다.

expect(response).toMatchObject({
  status: 200,
  data: { id: expect.any(Number), mode: 'approved' },
})

DB 데이터: 테스트마다 만들고, 정리 시점을 정한다

전역 시드·픽스처에 기대지 않는다. 테스트마다 필요한 레코드를 직접 넣고 그 레코드에만 작용한다. 시드를 공유하면 한 테스트의 수정이 다른 테스트를 깨뜨린다. 성능이 꼭 문제라면 데이터를 바꾸지 않는 조회 테스트에만 시드를 쓴다.

정리 시점은 테스트를 쓰는 방식을 정한다.

트랜잭션 롤백으로 격리하는 방법은 관계형 DB에서만 되고, 코드 안에 트랜잭션이 중첩되면 복잡해진다.

그 밖의 백엔드 기법

테스트의 효과 측정

커버리지는 실행 여부만 알려 준다. 단언 없이 함수를 부르기만 해도 100%가 나온다. 뮤테이션 점수가 테스트가 실제로 무엇을 지키는지 더 잘 보여 준다.

CI에서 지킬 것

파이프라인 자체를 짤 때의 원칙:

• 설정은 선언형으로 쓰고, Docker를 기본 지원하는 CI를 고른다.
• 빨리 실패한다. 린트·단위 테스트 같은 빠른 검사를 첫 단계에 묶어 커밋한 사람에게 바로 알린다.
• 테스트·커버리지·뮤테이션 리포트와 로그 같은 산출물을 쉽게 훑어볼 수 있게 남긴다.
• 기능 브랜치 커밋과 main PR처럼 이벤트마다 파이프라인을 나누고, 공통 단계는 재사용한다.
• 비밀 값은 파이프라인 정의에 넣지 않고 비밀 저장소에서 가져온다.
• 릴리스 빌드에서 버전을 명시적으로 올리거나, 올렸는지 확인한다.
• 한 번 빌드한 산출물(Docker 이미지 등)로 모든 검사를 한다.
• 빌드 사이에 상태가 남지 않는 일회용 환경에서 돌린다. node_modules 캐시 정도만 예외다.

자세한 파이프라인 구성은 CI/CD에 있다.

정리

• 테스트는 단순하고 짧게, 보자마자 이해되게 쓴다. 나머지 원칙은 모두 여기서 나온다.
• 이름에 대상·상황·기대를 담고, AAA로 나누고, 공개된 동작만 검증한다. 결과를 정하는 데이터는 테스트 안에 보이게 둔다.
• 대역은 요구사항을 확인할 때만 쓰고, 내부 호출을 세는 목은 피한다. 외부 서비스는 네트워크에서 가로채 지연·타임아웃·일시 실패까지 흉내 낸다.
• 백엔드 동작은 응답·새 상태·외부 호출·메시지·관측 가능성 다섯 가지 결과로 검증한다. DB 데이터는 테스트마다 만들고 정리는 전체가 끝난 뒤에 한다.
• E2E는 핵심 흐름만, sleep 대신 자동 대기. 커버리지는 하한선일 뿐이고 뮤테이션 테스트가 테스트의 힘을 잰다.

관련 노트: 프론트엔드 테스트의 종류와 도구, 백엔드 테스트, 험블 객체 패턴, 접근성 기반 UI 테스트 자동화, 프론트엔드에서의 TDD, CI/CD, 테스트의 기본 요소, 테스트를 돌리는 시점, 복원력 패턴