인지부하 최소의 React 테스트를 찾아서 1

좋은 React 테스트 방법 가설

2026-02-226 min read
reacttest

제목의 '인지부하 최소'란 읽고 쓰기 가장 편한 테스트를 찾는다는 뜻이다.

결론

  1. AI 개발 자동화와 개발자가 오류를 쉽게 보고 받기 위해 자동화된 테스트가 필요하다.
  2. 테스트가 어려운 이유는 한 컴포넌트에 책임이 너무 많기 때문이다.
  3. 좋은 테스트를 짜려면 컴포넌트가 구체적인 역할 단위로 hook, component로 나뉘어야 한다. (자세한 방법은 글 참조)

1. 테스트의 목표

1-1. AI 개발 자동화

Test Code가 없이는 프론트엔드 개발에서 자동화가 되는 부분은 코드 작성 뿐이다. 작업 완료 여부를 검증하는 일, 미흡한 부분을 찾는 일, 수정 방법에 대한 가이드 등은 모두 개발자의 몫으로 남아 있다.

[Why]

  • AI에게 프론트엔드 개발의 완료 조건은 모호한 상황.
    • 현재 프론트엔드 개발에서 AI 활용의 병목은 Token이 아니라 개발 시간(노가다 공수).
      • 작업의 완료 조건을 컴퓨터가 스스로 확인할 수 없다는 점이 그 원인이므로 해결이 필요

[How]

  1. 완료 조건을 최대한 객관화/정량화
  2. 세부적인 Task에 대한 완료 조건 검증 (더 추상적인 작업을 맡기기 위해)

1-2. 개발자를 위한 오류 보고

아래 사항들을 '자동으로' 알기 위해서

  1. 현재 기능을 잘 만들었는지
  2. 이전 기능들이 아직도 잘 동작하는지

2. 좋은 테스트 방법론

좋은 테스트 방법론은 2가지에 관한 것

  1. 의미 있는 테스트 케이스를 작성하는 방법
  2. 그 과정에서 '나쁜' 테스트 작성/유지보수 경험을 최소화

2-1. 테스트의 어려움

코드 라인을 최소화하고자 컴포넌트 하나에 책임을 다 부여하면 테스트가 어렵다.

[Example]

  1. HTTP API 호출을 1개 이상 수행
  2. 여러가지 오류 상황을 모두 직접 처리 (early return 등으로 오류 화면을 표시하는 등)
  3. 비즈니스 로직(계산, 매핑 등)을 처리
  4. DOM 관련 동작을 처리 (image lazy load 등)
  5. 상태 변화를 처리 (useState, useEffect 기반의 변화)
  6. 외부 저장소와의 연계 (localStorage 등)
  7. Date 기반의 연산 (new Date() 등)
  8. 사용하고 있는 Router 라이브러리에서 값을 조회 (Route.useParams() 등)

[Why]

  1. Test Case가 간단명료하게 떠오르지 않는다. (검증 대상부터 간단명료하지 않다)
  2. 아주 간단한 Input/Output TC도 준비물(Mock)이 많아서 시나리오가 길다.
  3. 간접적인 Input이 많아서 Mock 할 것들이 많아 코드가 명쾌하지 않다. (vs 단순 호출)
  4. 검증할 Case가 많다. (입력에 따라 가능한 상태/출력이 많다.)

2-2. 해결 가설 (Basic)

[How]

  1. 원래 컴포넌트를 더 구체적이고 작은 책임을 갖는 function, hook, component로 분리 (단위 테스트 대상)
    • e.g. props -> View 조각 여러개로 구성
    • e.g. 외부 의존성은 1-2개로 제한해서 Mock의 필요성이 명확하도록 구성
  2. (1)로 분리된 요소들을 합치는 역할을 하는 component 추가 (통합 테스트 대상)
  3. (2)의 복잡도가 낮게 유지되도록 합치는 단위를 적게 유지 (쉬운 테스트를 위해)
  4. 개별 책임을 갖는 요소는 다양한 시나리오로 검증
  5. 통합 책임을 갖는 요소는 최소한의 시나리오로 검증

2-3. 해결 가설 (Advanced)

  • Mock 대신 Fake 활용 등으로 재현 코드 길이 및 복잡성 최소화
    • Mock보다 Fake가 쉽고 재사용 가능
  • 외부 도구 대신 직접 Fake 구현을 선호
    • msw 와 같은 도구 사용 시 도구 이해 및 타 도구와의 연동 이슈로 불편
    • 대신 Fake를 사용하려면 구현체 타입 대신 interface 타입을 사용 (props, context로 주입)

3. 테스트의 한계

3-1. (아직) 할 수 없는 것

  • 디자인과 100% 일치하는지 확인

3-2. 할 수 있는 것

  • Pixel Diff: 직전 구현체와의 변경점을 바탕으로 의도하지 않은 변경 여부를 쉽게 확인 (e.g. Chromatic)

To-do

  • 해당 방법론을 실천하고 배운점을 바탕으로 좋은 예시, 안 좋은 예시, 구체적인 가이드라인을 수립해 2편을 작성