테스트 코드 작성해보기

테스트 코드의 중요성을 체감하고 있었지만, 바쁘다는 이유로 제대로 작성하지 못하는 경우가 많았다.
신규 기능이 얽혀 있을수록 테스트 코드의 필요성은 더 커지는데도, 현실에선 버그배시 전에 내가 직접 모든 케이스를 조합해 보고 이슈를 잡아내는 걸 반복했었다. 만약 초기에 몇 개 작성하더라도, 기능이 업데이트될 때마다 테스트 코드도 함께 유지보수해야 하는데, 그 과정을 놓치다 보면 테스트는 금세 실제 동작과 어긋난 상태가 되는 경우가 허다했다. 결국 무의미한 테스트만 쌓이게 되고, 테스트 자체를 작성하지 않는 흐름으로 이어지곤 했는데, AI가 발전한 지금, 테스트 코드 작성은 필수이지 않을까? 하는 생각이 들었다. 예전에 조건 분기랑 렌더링 케이스가 워낙 많아서, 테스트 코드가 있었으면 훨씬 수월했을 텐데... 싶었던 컴포넌트 트리를 이번엔 통째로 커서에게 넘겨 테스트 코드를 생성해보게 했다.
 
해당 컴포넌트는 아래와 같은 다양한 조건 조합에 따라 렌더링 결과가 달라지는 구조였다.

• 정답 수 숨김 여부
• 정답의 순서를 고려하지 않는 옵션
• 읽기 모드
• 정답 숨기기 설정
• 학생 답안이 정답 수보다 많은 경우
• ....

아래는 커서가 생성한 테스트 중 일부다. 

it('hideCorrectAnswer가 true일 때 정답이 표시되지 않아야 한다', () => {
  const props = {
    ...defaultProps,
    editor: {
      options: { hideCorrectAnswer: true },
    },
  };

  render(
    <I18nProvider i18n={i18n}>
      <ResultComponent {...props} />
    </I18nProvider>,
  );

  const orderedResult = screen.getByTestId('ordered-result');
  expect(orderedResult).not.toHaveTextContent(/Correct:/);
});

 
기본 렌더링이나 조건 분기 결과를 일일이 UI에서 확인하지 않아도 테스트로 빠르게 검증할 수 있었다.
 
물론 커서가 생성한 코드가 다행히도 완벽하진 않았다. 예를 들어 descendants로 내려오는 정답 수와 정답 배열 길이가 다를 때 보여줘야 하는 필드는 단순한 길이 비교가 아니라 도메인 정책에 따라 판단해야 했기 때문에, 해당 테스트 로직은 직접 수정해줘야 했다. 또한 테스트를 작성하려면 mock 정리가 먼저 필요했는데, 컴포넌트 내부에는 여러 하위 컴포넌트가 포함되어 있었고, 전체 구조를 그대로 테스트에 넣기엔 복잡도가 지나치게 높았다. UI와 직접적인 관련이 없는 부분은 전부 mock 처리했고, 아래처럼 단순한 형태로 대체했다.

jest.mock('../../ResultItemComponent', () => ({
  __esModule: true,
  default: ({ items, answers }) => (
    <div data-testid="ordered-result">
      <div>Answers: {items.map((item) => item.correctAnswer).join(', ')}</div>
      <div>Student Answers: {answers.map((item) => item.answer).join(', ')}</div>
    </div>
  ),
}));

 
해당 테스트는 하위 컴포넌트의 렌더링 결과를 정확히 검증하는 목적보다는, 상위 조건 분기에 따라 어떤 UI가 표시되는지를 확인하는 데 초점을 두는 게 더 적절하다고 판단했기 때문에 mock 구조도 분기 테스트에 필요한 수준까지만 구성하였다.
 
상위 컴포넌트의 분기 테스트를 마친 뒤, 하위 컴포넌트들 중 하나도 커서에게 테스트 코드 생성을 시켜봤다.

it('학생 답안이 정답과 일치할 때 A 상태가 표시되어야 한다', () => {
  const props = {
    ...defaultProps,
    studentAnswers: [
      {
        id: '1',
        answer: 'correct answer',
        type: Type.Text,
      },
    ],
  };

  render(<ResultItemComponent {...props} />);
  expect(screen.getByTestId('state')).toHaveTextContent('A');
});

 
해당 테스트 코드에서도 일부 타입 에러나 정책과 다른 부분들이 있었지만, 직접 수정해 주니 문제없이 동작했다.

이번에 다룬 컴포넌트 트리는 단순한 렌더링이 아니라, 옵션과 상태에 따라 다양한 분기 처리가 필요한 구조라 내 기준에서는 테스트 작성 난이도가 꽤 높았지만, 커서가 기본 구조를 잡아준 덕분에 빠르게 시작할 수 있었고, 이후 세부 정책만 보완하면 되는 형태라 효율도 높았다.
앞으로는 테스트 코드 없이 넘어가는 일은 없어야겠다는 생각이 들었다. 🔥