프론트엔드 테스트 코드에 대해서

RISTRETTO·2025년 5월 14일
테스트코드프론트엔드
0

프론트엔드

목록 보기
4/4

1. 코드 테스트의 의미와 필요성

테스트 코드를 작성하면 오류를 잡을 수 있나요?

테스트 코드 작성은 프로덕트가 배포되기 전 사전에 결함을 찾는데 도움을 줍니다.
하지만 테스트 코드를 작성했다고 프로덕트에 오류가 없다고 말할 순 없습니다.
보통 테스트 커버리지 100%를 채울 수 없고, 테스트 코드 또한 사람에 의해 작성되기 때문입니다.

그러면 왜 테스트 코드를 작성하나요?

1. 말뿐이 아닌 동작하는 명세
테스트 코드는 개발자가 작성한 코드의 실제 동작 예시를 구현함으로,
다른 개발자가 코드를 읽을 때 코드의 동작의도를 명확하게 파악하는데 도움을 줍니다.

2. 프로덕트의 좋은 설계로 가는 가이드가 된다

테스트 코드를 작성하다보면, 결합도가 높은 컴포넌트가 페이지 등을 만났을 때 테스트 작성의 곤란함을 느끼게 됩니다. 이러한 곤란함은 기존 코드의 설계에 대해 고민하게 하고, 결합도를 낮추는 가이드가 됩니다.



3. 리팩터링의 안전장치가 된다

거대한 모듈 혹은 페이지를 리팩터링 해서 여러가지 파일과 컴포넌트로 나눠야하는 일이 생겼을 때,
리팩터링 후 기존의 구현이 문제가 생기진 않을까, 잘 작동할까 걱정해본적 있지 않으신가요?
또한 리팩터링 후 기존 코드로 진행했던 QA를 개발자가 다시 한번 진행 해야 할 것 입니다.

테스트 코드는 “결과의 변경 없이” 코드를 수정하는데 도움을 줍니다.
마찬가지로 타인이 작성한 코드를 유지보수하고 수정 할 때에도, 
기존의 동작이 제대로 구현되는지 확인하고 안전하게 새로운 기능을 추가 할 수 있습니다.



4. Side Effect를 방지한다


같이 협업을 하다보면, 프로젝트 전체에서 사용되고 있는 Util 함수를 수정해야 할 때도 있고,
이미 선언되어서 사용되고 있는 Interface의 속성을 Optional로 바꾸거나 타입을 변경해야 하는 경우도 있습니다.
이런 때에 공통 모듈을 수정 후 전체 테스트를 돌림으로써 기존에 의도된 코드들이 정상으로 작동하는데 도움을 얻을 수 있습니다.

2. 예시

유닛 테스트

  • 유닛 테스트 혹은 단위 테스트라고 부릅니다. 단일 함수와 컴포넌트에 대해서 테스트합니다.
  • 아래는 onClick 함수를 prop으로 받아서 클릭 할 수 있는 버튼 컴포넌트에 대한 테스트입니다.
function Button({ onClick }: { onClick: () => void }) {
  return <button onClick={onClick}>클릭</button>;
}


describe('버튼 유닛 테스트', () => {

  it('버튼을 클릭하면 전달받은 함수를 실행한다..', () => {

    // 먼저 vitest를 사용해서 가상 함수를 선언합니다.
    const handleClick = vi.fn();


    // Button 컴포넌트를 node기반의 가상환경에서 렌더하면서 위에서 만든 함수를 전달합니다.
    const { getByText } = render(<Button onClick={handleClick} />);


    // 클릭 텍스트를 가진 dom을 찾아서 클릭 합니다.
    fireEvent.click(getByText(/클릭/i));


    // 위에서 선언한 handleClick 함수가 1번 실행되었는지 확인합니다.
    expect(handleClick).toHaveBeenCalledTimes(1);
  });
});

통합 테스트

  • 통합 테스트는 여러 모듈과 컴포넌트 간의 상호관계, 로직의 flow를 테스트 합니다.
  • 아래는 이메일을 입력하고 버튼을 클릭하면 “로그인 성공”이라는 텍스트를 띄우는 
간단한 예시 페이지에 대한 테스트 입니다.

function LoginPage() {
  const [email, setEmail] = useState('');
  const [submitted, setSubmitted] = useState(false);

  const handleSubmit = () => {
    if (email) setSubmitted(true);
  };

  return submitted ? <p>로그인 성공</p> : (
    <div>
      <input placeholder="email" onChange={e => setEmail(e.target.value)} />
      <button onClick={handleSubmit}>로그인</button>
    </div>
  );
}


describe('로그인 페이지 통합테스트', () => {

  it('이메일을 입력하고 로그인을 누르면 "로그인 성공" 메시지가 출력된다..', () => {

    // 먼저 로그인 페이지를 node기반의 가상환경에서 렌더합니다.
    render(<LoginPage />);

    // placeHolder가 email인 것을 찾고 value로 이메일을 넣습니다.
	fireEvent.change(screen.getByPlaceholderText(/email/i), {
      target: { value: 'user@example.com' }
    });

    // 로그인 버튼을 찾아서 클릭합니다.
    fireEvent.click(screen.getByText(/로그인/i));

    // 로그인 성공 메시지가 화면에 출력됐는지 확인합니다.
    expect(screen.getByText(/로그인 성공/i)).toBeInTheDocument();
  });
});

3. 컨벤션

단일 책임 원칙

  • 하나의 테스트 함수 단위 (it, test) 에서는 하나의 동작만 검증합니다.
it('탭 클릭시 탭이 변경되고, 변경된 탭에 대한 내용이 표시된다')
-> X

it('탭 클릭시 탭이 변경 된다')
it('선택된 탭에 대한 내용이 표시된다') 
-> O

코드 컨벤션

  • 테스트 파일명 - *.test.ts 또는 *.spec.ts 를 사용합니다
  • 테스트 함수명 - it() 함수 또는 test() 함수를 사용합니다.
  • 테스트 디렉토리명 - tests 디렉토리를 사용합니다.
    경우에 따라 __test__, __mock__ 을 사용합니다.

테스트 코드 위치

  1. 테스트 할 코드와 동일한 디렉토리 레벨에 tests 디렉토리를 만들고 해당 디렉토리에테스트 파일을 생성합니다.
Ex)
src/components/button/Button.tsx
src/components/button/tests/Button.spec.tsx
  1. setupTest 파일, 테스트 글로벌 파일의 경우 src 디렉토리 레벨의 test 디렉토리 혹은 util 디렉토리 내부의 test 디렉토리에 생성합니다.
Ex)
src/test/setupTest.ts
src/utils/test/setupTest.ts

4. 커버리지

커버리지란

  • 전체 테스트 케이스가 전체 소스코드의 얼마나 많은 부분을 실행하고 있는지 수치로 표현합니다.
  • 아래는 기준입니다.
Statement Coverage : 각 구문이 최소 1회 이상 실행됐는지 측정
Branch Coverage : 조건문(if/else)의 각 분기가 실행됐는지 측정
Function Coverage : 정의된 함수들이 최소 1회 이상 호출됐는지 측정
Line Coverage : 각 라인이 최소 1회 이상 실행됐는지 측정
  • 출력 예시

5. 무엇을 테스트 해야 하는가?

잘 깨지지 않는 테스트를 작성하라

에러나 버그를 회피하라는 것은 아닙니다.
내부 구현보다 인터페이스에 초점을 맞춰야 한다는 얘기입니다.
프론트 테스트 코드는 자바스크립트 자체를 테스트하기 보다, 사용자 중심으로 테스트 해야합니다.
예시를 들어보겠습니다.

나쁜예 -> it('button을 클릭했을때 표시되는 modal의 postion은 "absolute"이다')
좋은예 -> it('button을 클릭했을때 modal이 생성된다')


나쁜예 -> it('checkBox를 클릭했을때 checkBox의 checked 값이 true 이다')
좋은예 -> it('checkBox를 클릭했을때 Checked Icon이 화면에 표기된다.')
나쁜예 -> it(fetching시 isLoading의 상태가 'true'이다)
좋은예 -> it(fetching시 화면에 LoadingSpinner 컴포넌트가 생성된다)

사용자 측면과 요구사항의 결과는 같은데,
코드 변경에 따라 테스트가 계속해서 깨진다면 유지보수 하기 어려운 테스트가 됩니다.

우선순위가 높은 코드부터

  1. 공통 모듈, 재사용성이 높은 코드
  2. 명세가 없으면 이해하기 어려운 코드
  3. 핵심 로직

의미있는 테스트

  1. 커버리지 만을 올리는 테스트는 작성 할 이유가 없습니다. 
예시로 단순히 UI 만을 올리는 컴포넌트, 에러가 발생할 가능성이 없는 간단한 함수 등은 테스트 할 필요가 없습니다.
Ex) 테스트 하지 않아도 되는 코드들

function Label (label:string){
  return <label>{label}</label>
}

const isString => (value) => typeof value === 'string';

테스트 코드는 견고한 프로덕트를 만드는데 도움이 되지만,
동시에 개발자의 리소스를 더 사용하게 될 수 밖에 없습니다.

배포된 버전에 문제가 있는데, 테스트 코드를 수정하고 있기는 어려울 것 입니다.
중간 지점을 잘 찾아서 좋은 도구로 사용했으면 좋겠습니다.

profile
RISTRETTO
빛나는 개발자
이전 포스트

Vite의 공략대상이 되어버렸습니다.

0개의 댓글