렌더링 테스트와 스냅샷 테스트에 대해

 

 

1. 렌더링 테스트와 스냅샷 테스트의 차이

 

# 렌더링 테스트:

- 정확한 요소나 속성의 존재 여부를 확인하는 데 사용해

- 각각의 요소가 제대로 렌더링되었는지, 그리고 그 값이나 속성이 기대한 대로 표시되었는지를 세밀하게 검증할 수 있어.

- 예를 들어, 이미지의 src 속성, 텍스트가 제대로 표시되는지, 동적 데이터가 제대로 반영되었는지 확인하는 데 유용해.

 

it('renders video item', () => {
  render(withRouter(<Route path='/' element={<VideoCard video={video} />} />));

  // 요소 존재 여부 확인
  const image = screen.getByRole('img');
  expect(image).toHaveAttribute('src', thumbnails.medium.url);
  expect(image).toHaveAttribute('alt', title);

  expect(screen.getByText(title)).toBeInTheDocument();
  expect(screen.getByText(channelTitle)).toBeInTheDocument();
  expect(screen.getByText(formatAgo(publishedAt, 'ko'))).toBeInTheDocument();
});

이 테스트는 매우 구체적이야. 각 UI 요소(이미지, 텍스트 등)의 속성과 내용을 테스트해서 원하는 결과가 정확히 나오는지 확인해.

 

# 스냅샷 테스트

- 컴포넌트가 전체적으로 렌더링된 모양을 스냅샷으로 저장하고, 나중에 그 구조가 바뀌었는지 확인하는 데 사용해.

- 하나하나의 요소보다는 전체 컴포넌트으 구조가 바뀌었는지, 예상하지 못한 변경이 있는지 파악하는 데 적합해.

 

test('renders VideoCard correctly', () => {
  const { asFragment } = render(<VideoCard video={video} />);
  expect(asFragment()).toMatchSnapshot();
});

이 스냅샷 테스트는 렌더링된 컴포넌트 전체를 캡처해서 이후 변환된 구조를 비교해. 스냅샷이 바뀌면, 구조가 의도한 대로 변경되었는지 검토한 후에 스냅샷을 업데이트할 수 있어.

 

---

 

2. 어떤 상황에서 렌더링 테스트가 적합할까?

 

- 구체적인 동작을 검증할 때. 예를 들어, 이미지 src가 특정 URL로 설정되는지, 텍스트가 올바르게 표시되는지와 같이 정확한 값을 확인해야 하는 경우 렌더링 테스트가 적합해.

 

- 동적인 값이 렌더링 될 때, 예를 들어 서버에서 받아온 데이터를 컴포넌트가 올바르게 표시하는지, 특정 상호작용에 따라 렌더링 결과가 바뀔 때도 렌더링 테스트를 사용해.

 

3. 어떤 상황에서 스냅샷 테스트가 적합할까?

 

- UI 구조가 의도치 않게 변경되는 것을 방지하고 싶을 때.

- 컴포넌트가 복잡한 구조를 가질 때(하위 컴포넌트가 많거나, 정적인 요소가 많을 때).

- 큰 UI에서 많은 부분이 변경되지 않는 경우 전체 구조의 변화를 빠르게 감지하는 데 유용해.

 

4. 결론

 

- 렌더링 테스트는 UI 요소와 그 요소의 세부적인 동작이나 값을 정확히 테스트하는 데 적합해. 예를 들어, 이미지의 src, 텍스트가 올바른지 등을 테스트할 때.

 

- 스냅샷 테스트는 컴포넌트의 전체 구조가 바뀌었는지 확인할 때 유용하지만, 세부 동작 검증에는 적합하지 않아.

 

렌더링 테스트는 요소들이 의도한 대로 동작하는지 확인하는 데 적합하고, 스냅샷 테스트는 전체적인 구조 변화를 감지하는 데 유용해. 상황에 따라 둘을 적절히 조합해서 사용하는 것이 좋다.

 

---

 

# 스냅샷 테스트 방식

사실 스냅샷 테스트의 문법이 크게 바뀌지는 않았지만, 최근에는 react-testing-library와 같은 도구를 많이 사용하면서 스냅샷 테스트도 조금 더 간결하게 작성하는 방법이 선호되고 있다. 예전처럼 react-test-renderer의 renderer.create 방식도 여전히 사용 가능하지만, @testing-library/react의 render를 사용하는 방식이 좀 더 직관적이고 간단하다는 차이가 있다.

이전 방식 (react-test-renderer)

import renderer from 'react-test-renderer'; // react-test-renderer를 사용

it('renders grid type correctly', () => {
  const component = renderer.create(
    withRouter(<Route path='/' element={<VideoCard video={video} />} />)
  );
  expect(component.toJSON()).toMatchSnapshot();
});

 

현재 선호되는 방식 (react-testing-library)

import { render } from '@testing-library/react'; // react-testing-library를 사용

it('renders grid type correctly', () => {
  const { asFragment } = render(
    withRouter(<Route path='/' element={<VideoCard video={video} />} />)
  );
  expect(asFragment()).toMatchSnapshot();
});

 

차이점:

1.react-test-renderer vs @testing-library/react:
- react-test-renderer: DOM을 직접 시뮬레이션해서 컴포넌트를 렌더링해, 그 결과를 toJSON() 메서드를 통해 스냅샷으로 변환.
- @testing-library/react: 브라우저 환경에 더 가까운 방식으로 DOM을 렌더링하며, asFragment()를 사용해 스냅샷을 더 직관적으로 관리.

 

2. 간결성

- react-testing-library의 asFragment 방식이 훨씬 간결하고 유지보수하기 쉬움. 특히, asFragment는 특정 부분만 렌더링해서 테스트할 수도 있어 유연성이 높음.

결론적으로, 최신 트렌드에 맞추려면 react-testing-library를 사용한 방식이 더 적합할 수 있다. 특히, 다양한 테스트 케이스를 다룰 때 @testing-library/react는 사용자 인터페이스와 상호작용하는 테스트에 더 유리한 도구야.