단위 테스트 대상 선정하기

저번시간에 보았던 단위테스트가 무엇인가 돌아보자면, 다른 컴포넌트와의 상호작용이 아닌 단일 컴포넌트를, 그 컴포넌트가 예상대로 동작하는지 확인하는 테스트이다.
그래서 Atomic 컴포넌트라고 불리는 것들이 단위테스트의 주 대상이라고 했다.

하지만 반면 또 너무 단순한 경우(단순한 ui 렌더링, 간단한 로직)에는 일일이 단위테스트를 거칠 필요 없이 다른 컴포넌트들과 함께 (상위 컴포넌트에서) 통합테스트에서 검증하는것으로도 충분하다.

리액트 훅, 유틸함수

컴포넌트 외에도 리액트 훅과 유틸 함수도 단위 테스트의 대상이 된다. (단위 테스트로 검증하기 매우 적합하다)

유틸 함수는 보통 여러 컴포넌트에서 공통적으로 사용되는 함수들이고 다음과 같은 특징들을 가지고있다 :

• 순수 함수 : 함수 외부의 상태를 변경하는 등, 외부와 상호삭용 하지 않는 함수. (불변 상수 단순 참조는 제외)
• UI 로직과 무관
• 비즈니스 로직 : 계산, 변환, 검증 등의 순수한 로직

모듈 모킹

shopping-mall-unit-test 브랜치에서 EmptyNotice와 NotFoundPage,ErrorPage 컴포넌트들을 단위 테스트 한다.

• EmptyNotice : 장바구니가 비어있는 상태에서 장바구니 페이지로 이동시에 장바구니가 비어있다고 보여주는 컴포넌트
  • 이 컴포넌트는 사실 여러 컴포넌트들이 조합되어 이루어진 컴포넌트임에도 불구하고 홈으로 이동한다는 하나의 기능만 가지고 있기 때문에 독립적인 컴포넌트라고 볼 수 있다.
• NotFoundPage : 사용자가 잘못된 경로로 이동했을 때 보여주는 페이지
• ErrorPage : 예상하지 못한 오류가 발생했을 때 보여주는 페이지
  • 두 에러 페이지 모두 페이지 단위의 큰 컴포넌트임에도 불구하고 굉장히 단순한 구성 요소를 가지고있고 마찬가지로 '뒤로 이동'과 같은 간단한 기능만 가지고 있기 때문에 단위 테스트로 검증할 수 있다.

그런데 위 세 컴포넌트 모두 react-router-dom의 useNavigate()훅을 가져와 사용하고있다. (즉 react-router-dom에 의존성을 가지고 있다.)
이 컴포넌트들을 단위 테스트 할때는 해당 기능을 제대로 호출하는지만 검증하면 된다. (외부 모듈의 검증은 해당 모듈 자체에서 테스트를 통해 검증할 일이지 참조하고 있는 여기서 할 일은 아님)
그리고 이 외부 모듈의 특정 기능을 제대로 호출하는지 알아보기 위해 모킹이라는 것을 한다.

모킹 : 실제 모듈,객체와 동일한 동작을 하도록 만든 모의 모듈,객체로 실제를 대체하는 것.

• 모킹을 통해 우리는 외부 모듈과 검증할 모듈을 분리해서 필요한 검증만 진행할 수 있다.
• 그러나 실제 모듈과 완전히 동일한 모의 객체를 구현하는 것은 큰 비용이 드는 작업이며, (정확히 무슨뜻일까?)
• 모의 객체를 남용하는 것은 테스트 신뢰성을 낮추는 결과를 낳는다.

const navigateFn = vi.fn();

vi.mock('react-router-dom', async () => {
  const original = await vi.importActual('react-router-dom');

  return { ...original, useNavigate: () => navigateFn };
});

it('Home으로 이동 버튼 클릭시 홈 경로로 이동하는 navigate가 실행된다', async () => {
  const { user } = await render(<NotFoundPage />);

  const button = await screen.getByRole('button', { name: 'Home으로 이동' });

  await user.click(button);

  expect(navigateFn).toHaveBeenNthCalledWith(1, '/', { replace: true });
});

vi.mock()함수를 통해 react-router-dom의 모킹을 만든다.
그러면 <NotFoundPage /> 컴포넌트가 불러오는 해당 모듈은 진짜 모듈이 아닌 여기서 만들어진 모킹이 된다.
그 컴포넌트에서 useNavigate()를 호출할 다음과 같이 호출할 때

  const handleClickNavigateHomeButton = () => {
    navigate(pageRoutes.main, { replace: true });
  };
  
  return(
  ...
  <button onClick={handleClickNavigateHomeButton}>Home으로 이동</button>
  )

실제로 호출되는 것은 모킹에 넣었던 navigateFn 스파이 함수다.
그래서 expect()매처로 useNavigate()함수를 호출하면서 어떤 인자를 넣었는지 ("/", {replace : true})확인할 수 있게 된다.

모킹 초기화

위에서 useNavigate()와 react-router-dom 모듈을 모킹했다.
그런데 이 모킹이 다른 테스트에 영향을 줄 수 있는 경우(다른 테스트에서는 다른 방식으로 모킹을 해야한다던가)를 위해 테스트 수행 후에는 모킹을 초기화하는것이 좋다.

//setupTests.js
...

beforeAll(() => {
  server.listen();
});

afterEach(() => {
  server.resetHandlers();
  vi.clearAllMocks();
});

afterAll(() => {
  vi.resetAllMocks();
  server.close();
});

...

clearAllMocks() :

• 모킹된 모의 객체 호출에 대한 히스토리를 초기화
  • 히스토리가 초기화되지 않고 계속 쌓이면 호출 횟수나 인자가 변경되어 다른 테스트에 영향을 줄 수 있다.
• 모킹된 모듈의 구현을 초기화 하지는 않는다 (모킹된 상태로 유지)

resetAllMocks() :

• 모킹된 모듈의 구현을 초기화

리액트 훅 테스트

강의에서 사용하는 예제의 구조는 이렇다.
<NavigationBar />안에 <ConfirmModal /> 컴포넌트가 있다.
그리고 이 모달을 표시하고 안하고를 isModalOpened라는 상태로 결정하는데,
그 상태 관리를 <NavigationBar />컴포넌트 안에서 useState()훅을 사용해 직접 관리하지 않고,
useConfirmModal()이라는 커스텀 훅으로 분리시켜 관리한다.

import { useState } from 'react';

const useConfirmModal = (initialValue = false) => {
  const [isModalOpened, setIsModalOpened] = useState(initialValue);

  const toggleIsModalOpened = () => {
    setIsModalOpened(!isModalOpened);
  };

  return {
    toggleIsModalOpened,
    isModalOpened,
  };
};

export default useConfirmModal;

이렇게 커스텀 훅으로 분리해 상태를 관리하면 똑같은 기능을 필요로 하는 다른 컴포넌트에서도 사용할 수 있어 코드의 재사용성이 높아진다는 장점 외에도 다음과 같은 장점이 있다.

• 관심사 분리로 인한 가독성 향상
• 로직 캡슐화로 인한 테스트 용이성 증가

renderHook

테스팅라이브러리에서 제공하는 API.

리액트 훅을 검증하기 위해서는 훅을 호출하고 난 후에 훅이 반환하는 isMOdalOpened와 같은 상태가 올바르게 변경되는지 확인해야 한다.
그런데 리액트 규칙상 리액트 훅(리액트 자체 훅, 커스텀 훅 모두)은 리액트 컴포넌트 안에서만 호출할 수 있다는 것이다.
지금 테스트를 하고있는 파일인 useCOnfirmModal.spec.jsx는 리액트 컴포넌트가 아니기때문에 (일반 js파일) 훅을 호출할 수 없지만, 이를 해결하기 위해 renderHook() api를 사용하면 호출할 수 있다.

const { result, rerender } = renderHook(useConfirmModal);
// or
const { result } = renderHook(() => useConfirmModal(true));

expect(result.current.isModalOpened).toBe(false);
// or 

result : 훅을 호출하여 얻은 결과 값.
rerender : 훅을 원하는 인자와 함께새로 호출하여 상태를 갱신. (강의에서는 보여주기만 하고 사용은 안한다?)

act 함수

상호 작용(렌더링, 이펙드 등)을 함께 그룹화하고 실행해 렌더링과 업데이트가 실제 앱이 동작하는 것과 유사한 방식으로 동작함.

• 즉 act를 사용해야 테스트 환경의 가상의 돔(jsdom)에 제대로 반영된다.
  컴포넌트를 렌더링한 뒤 업데이트 하는 코드의 결과를 검증하고 싶을때 사용.

그런데 왜 이전 단위 테스트(UI 컴포넌트)에서는 act함수가 없이 테스트를 수행할 수 있었을까?
왜냐하면, render 함수 자체에서 내부적으로 act 함수를 사용하기 때문.

// 실패
it('훅의 toggleIsModalOpened()를 호출하면 isModalOpened 상태가 toggle된다.', () => {
  const { result } = renderHook(useConfirmModal);
  result.current.toggleIsModalOpened();
  expect(result.current.isModalOpened).toBe(true);
});

//성공
it('훅의 toggleIsModalOpened()를 호출하면 isModalOpened 상태가 toggle된다.', () => {
  const { result } = renderHook(useConfirmModal);
  act(() => {
    result.current.toggleIsModalOpened();
  });
  expect(result.current.isModalOpened).toBe(true);
});

타이머 테스트

디바운스 : 특정 함수의 호출 횟수를 제한

• 주로 스크롤처럼 대량의 이벤트 핸들러가 발생할 때 성능 개선을 목적으로 사용

export const debounce = (fn, wait) => {
  let timeout = null;

  return (...args) => {
    const later = () => {
      timeout = -1;
      fn(...args);
    };

    if (timeout) {
      clearTimeout(timeout);
    }
    timeout = window.setTimeout(later, wait);
  };
};

타이머 모킹

beforeEach(() => {
    vi.useFakeTimers();
});
afterEach(() => {
	vi.useRealTimers();
});
  
it('연이어 호출해도 마지막 호출 기준으로 지정된 타이머 시간이 지난 경우에만 함수가 호출된다.', () => {
    const spy = vi.fn();

    const debouncedFn = debounce(spy, 300);

    debouncedFn();
    vi.advanceTimersByTime(200);
    debouncedFn();
    vi.advanceTimersByTime(100);
    debouncedFn();
    vi.advanceTimersByTime(200);
    debouncedFn();
    vi.advanceTimersByTime(300);
    debouncedFn();

    expect(spy).toHaveBeenCalledTimes(1);
});

userEvent와 사용자 상호작용

fireEvent : userEvent처럼 리액트 테스팅 라이브러리에서 DOM 이벤트를 시뮬레이션 하기 위해 제공하는 api

userEvent vs fireEvent ?

fireEvent는 "해당 이벤트만 디스패치" 한다.

이게 무슨뜻이냐면, userEvent로 클릭 이벤트를 발생시킨다면 mouseOver -> mouseMove -> mouseDown -> mouseUp -> click 의 순서대로 실제 사용자가 사용할 때 처럼 여러 이벤트가 발생하지만,
fireEvent는 단순히 click 이벤트만 발생시킨다는 것.

이전 시간에 텍스트 인풋을 클릭하면 onFocus가 호출되는지 테스트를 했는데, 이 때 사용한것은 userEvent.
만약 fireEvent로 텍스트 인풋을 클릭한다면 onFocus가 호출되지 않는다.

그래서 되도록 userEvent 사용이 불가능한 경우가 아니라면 userEvent를 사용한다.

• 불가능한 경우 : ex.scroll

단위 테스트의 한계

저번 장에서 배웠듯, 단위 테스트는 앱에서 테스트 가능한 가장 작은 단위의 소프트웨어를 검증하는 것이다.
즉, 여러 모듈이 조합되어 상호작용할 때 발생하는 오류를 찾아내고 검증하지 못하는 아주 간단한 테스트이다.

그래서 수행하는 테스트가 통합테스트, E2E 테스트, 시각적 테스트 들이다.
통합테스트란 여러 모듈이 조합되었을 때 기능하는 비즈니스 로직을 검증하는 용도로 수행되는 테스트다.