[마무리] 프론트엔드 단위 테스트

🗂️ 단위 테스트

소프트웨어의 특정 모듈이나 기능이 올바르게 작동하는지를 검증하는 테스트로, 코드의 일부를 독립적으로 테스트하는 것

 

프론트엔드 테스트 종류

• 단위 테스트 (Unit Test) : 코드의 작은 단위나 개별 함수를 독립적으로 테스트하며, 빠르고 효율적이다.
• 스냅샷 테스트 (Snapshot Test) : 주로 UI의 변경 여부를 확인하여, 예상된 UI 상태와 현재 UI 상태가 일치하는지 비교한다.
• 종단 간(e2e) 테스트 (End-to-End Test) : 사용자 입장에서 전체 애플리케이션의 흐름을 테스트하여 시스템이 통합된 상태에서 작동하는지 확인한다.

단위 테스트의 장점 : 버그를 초기에 잡아내고, 코드 변경 시 예상하지 못한 오류를 방지, 유지 보수가 용이하며, 코드의 안정성을 높여준다.

 

---

🥇 F.I.R.S.T

단위 테스트 코드 작성 시 지켜야 할 원칙

• Fast : 테스트는 빠르게 수행해야함. 느린 테스트는 개발 흐름을 방해하고, 실행이 꺼려질 수 있습니다.
• Isolated : 단위 테스트는 서로 독립적으로 실행되어야한다. 서로 의존하지 않도록 설정한다.
• Repeatable : 환경에 영향받지않아 실행할 때마다 일관된 결과를 내야한다.
• Self-validating : 테스트는 결과가 ‘성공’ 또는 ‘실패’로 자동으로 평가되도록 작성해야한다.
• Timely/Thorough : 테스트를 미리 작성하여 코드의 기능과 동작을 검증하는 방식을 사용해야한다. => TDD(구현하고자 하는 기능을 미리 테스트로 작성)

 

🥈 DAMP

Descriptive And Meaningful Phrases : 읽기 쉽고 직관적인 코드 작성

• 의미 있고 서술적인 표현 사용: 코드가 단순히 작동하는 것을 넘어, 의도를 명확하게 전달할 수 있어야한다.
• DRY(Don't Repeat Yourself) 원칙과의 차이: 테스트 코드에서는 중복을 최소화하기보다 코드가 설명적이고 직관적인 것이 더 중요하다.

예시

중복을 제거한 깔끔한 코드가 아닌, 가독성과 명확성을 높인 코드가 장기적으로 유지 보수와 이해에 유리함.

아래 코드는 어떤 컴포넌트에서 특정 버튼을 클릭했을 때 특정 함수가 올바른 매개변수로 호출되는지를 확인하는 테스트 코드이다.

 

// 1번
it('설명을 생략하면 이해가 되시나요?', async () => {
    const user = userEvent.setup();
    render(<Component {...preDefinedProps} />);

    const buttonElement = screen.getByRole('button', { name: '버튼입니다' });
    await user.click(buttonElement);

    expect(doSomething).toBeCalledWith(1234);
});

// 2번
it('설명이 없어도 대충 느낌은 오시죠?', async () => {
    const something = 1234;
    const doSomething = vi.fn();
    const user = userEvent.setup();
    render(<Component {...preDefinedProps} something={something} doSomething={doSomething} />);

    const buttonElement = screen.getByRole('button', { name: '버튼입니다' });
    await user.click(buttonElement);

    expect(doSomething).toBeCalledWith(1234);
});

 

🥉 Given-When-Then

Given-When-Then 구조는 BDD의 중심인 사용자 행위를 기반으로 한 테스트 시나리오를 정의할 수 있도록 도와준다.

 

• Given: 테스트를 하기 위해 세팅하는 주어진 환경
• When: 테스트를 하기 위한 조건으로 프론트엔드에선 사용자와의 상호작용인 경우도 많음
• Then: 예상 결과를 나타내며 의도대로 동작하는지 검증 및 확인할 수 있음

Given-When-Then의 장점

• 테스트 코드가 명확하고 읽기 쉬워져, 협업 시 테스트 의도를 쉽게 공유할 수 있습니다.
• 로직의 흐름에 따라 자연스럽게 시나리오를 설정하고, 조건과 결과를 확인할 수 있습니다.

 

it('버튼을 1회 클릭하면 1번 클릭했다는 문구가 노출된다', async () => {
	const user = userEvent.setup();
	render(<Component />);

	const buttonElement = screen.getByRole('button', { name: '여기를 눌러보세요' });
	await user.click(buttonElement);

  	expect(screen.getByText('버튼을 1번 클릭했습니다.')).toBeInTheDocument();
});

 

---

🚥 개별 테스트 케이스의 목적은 명확히

it('버튼 클릭 시 좋아하는 과일이 바나나로 바뀐다', async () => {
  const user = userEvent.setup();
  render(<WordWithButton />);

  await user.click(screen.getByRole('button', { name: '좋아하는 과일 바꾸기' }));

  expect(screen.getByText(/바나나/i)).toBeInTheDocument();
});

의도하지 않은 곳에서 바나나가 출력되었을 수 있다.

동작에 대한 결과를 검증하는데 바나나는 출력되었지만 실제 상태변화가 나타났는지 확인할 수 없다.

 

it('버튼 클릭 시 heading 영역의 문구가 바나나를 좋아한다는 내용으로 변경된다', async () => {
  const user = userEvent.setup();
  render(<WordWithButton />);

  await user.click(screen.getByRole('button', { name: '좋아하는 과일 바꾸기' }));

  expect(screen.getByRole('heading', { name: '나는 바나나를 좋아한다!' })).toBeInTheDocument();
});

heading 영역에 나타나는지를 검증하고 있어 목적이 명확하다.

작성하는 테스트 케이스가 정확하게 어떤 것을 검증할 것인지 테스트 케이스의 목적을 생각하며 코드와 expect를 작성해야한다.

 

 

 

 

참고 : https://techblog.woowahan.com/17404/