단위 테스트

서론

유지보수를 하다보면 코드는 왜 이렇게 만들었을까? 요구사항은 왜 이럴까? 하는 경우가 종종 아니... 조금 많이 있는 것 같다.

특히, 오래전에 만들어진 코드라 구조자체가 그때 만든 사람만이 알 수 있고 에러가 나는 부분을 뜯어내고 새로 살을 붙여야하는데 이게 뭔 땜빵만해놔서 결국 별거아닌 부분 하나 수정하려고하면 땜빵난 전체 부분을 수정해야해서 결국 나도 땜빵을하게된다....

그에따라, 우리 팀은 새롭게 진행하는 프로젝트에 테스트코드를 만들어서 사전에 테스트 코드를 작성해서 불필요한 업무를 줄이고자 진행하게 되었습니다..!

 

본론

react-testing-library

테스트코드 패키지 jest는 당연히 사용하고 react가 가상 돔을 이용하기에 testing-library 패키지와 jest를 같이 사용합니다.주로, 프론트에서는 test를 값을 입력하고 해당 조건에 맞춰 false의 결과, true의 결과를 보여줍니다.예를 들어, 로그인에 실패하면 나오는 팝업 창 그리고 회원가입에 성공한 결과값

 

단위 테스트

단순하게 하나의 컴포넌트를 테스트합니다.아래 예시를 보여드리면

import React from 'react';

interface InputProps {
  type: string;
  placeholder: string;
  value: string;
  onChange: (_: React.ChangeEvent<HTMLInputElement>) => void;
}

const AuthInput = ({ type, placeholder, value, onChange }: InputProps) => {
  return (
    <input
      type={type}
      placeholder={placeholder}
      value={value}
      onChange={onChange}
    />
  );
};

export default React.memo(AuthInput);

 

input의 컴포넌트입니다.

import { render, screen, fireEvent } from '@testing-library/react';
import '@testing-library/jest-dom';
import AuthInput from './AuthInput';

describe('AuthInput Component Test', () => {
  it('Test id value', () => {
    render(
      <AuthInput
        type="text"
        placeholder="아이디"
        value=""
        onChange={() => {}}
      />
    );

    const inputElement = screen.getByPlaceholderText('아이디');
    expect(inputElement).toBeInTheDocument();
    expect(inputElement).toHaveAttribute('type', 'text');
  });

  it('Test pw value', () => {
    render(
      <AuthInput
        type="password"
        placeholder="비밀번호"
        value=""
        onChange={() => {}}
      />
    );

    const pwElement = screen.getByRole('textbox', { name: '비밀번호' });
    expect(pwElement).toBeInTheDocument();
    expect(pwElement).toHaveAttribute('type', 'password');
  });

  it('Test input value', () => {
    const mockOnChange = jest.fn();
    render(
      <AuthInput
        type="text"
        placeholder="아이디"
        value=""
        onChange={mockOnChange}
      />
    );

    const inputElement = screen.getByPlaceholderText('아이디');
    fireEvent.change(inputElement, { target: { value: 'test' } });

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

 

단순하게 AuthInput 컴포넌트에서 로그인, 비밀번호 입력 칸을 생성합니다.

그리고 3번째 단위테스트에선 렌더된 AuthInput에 아이디를 입력이 되고 변화하는지 까지 테스트를 합니다.

애초에 UI 관련 테스트가 주이기 때문에 큰 입력 -> 성공 및 실패 이런건 통합테스트에서 진행을 합니다.

제 개인적인 생각이지만 이러한 단위테스트가 합쳐져서 결국 통합테스트를 생성하게 되는 것 같습니다.

 

API관련해서는 할 말이 많지만 공식홈페이지나 다른 블로그 글 그리고 GPT한테 물어보는게 가장 좋습니다...

 

정리

테스트 코드는 단순 컴포넌트 단위부터 크게 사용자 경험(E2E)테스트까지 진행을 합니다.

jest와 testing-library로는 통합테스트까지 진행을 하는 것으로 알고있고 cypress가 단위 테스트부터 E2E 테스트까지 진행을 하는 것으로 알고 있습니다. 차차 cypress까지 진행하여 모든 테스트를 하고 싶지만 우선 하나하나 jest부터 진행해서 나중에 node.js부분도 같이 할 수 있게 공부를 하겠습니다.