TDD와 JEST
개인 프로젝트 진행 전 어떤 기술 스택을 사용할 것인지 고민해보면서 JEST를 도입해보려고 좀 알아보고자 정리해보았다. 이 포스트는 개념 위주의 정리인데 다음 포스트에서는 직접 테스트를 진행해보는 코드 위주의 글을 작성해야지!
🛠️ TEST의 필요성
TDD( Test Driven Development )란?
작성한 코드의 기능을 묘사하고,
동작을 검증할 테스트 코드를 먼저 작성해 빠르게 테스트를 진행하며 개발하는 방법
왜 TDD를 도입해야할까?
- 코드 퀄리티 향상
- 코드의 결함을 초기에 발견 가능
- 코드가 잘 디자인됐고, 요구사항을 충족하고 있다는 점을 확인 가능
- 더 좋은 문서화
- 시스템이 어떻게 동작해야 하는지에 대한 문서를 자동으로, 최신 상태로 작성 가능
- 잘 짜인 테스트 코드는 그 자체가 문서
- 팀 내의 커뮤니케이션 촉진
- TDD는 팀이 작성 중인 코드에 대해 같은 시야로 바라볼 수 있도록 도와주며, 잘못된 의사소통으로 인한 오해나 오류를 방지하는 데 도움이 됨
좋은 TEST란 무엇인가?
- 모든 테스트는 독립적으로 실행되어야 한다.
- 테스트의 결과는 일관성이 있어야 한다.
- 내부 구현에 종속된 테스트는 지양해야 한다.
- 테스트는 단순하고 이해하기 쉬워야 한다.
- 유지보수가 가능한 테스트를 작성해야 한다.
TEST의 종류
-
단위 테스트 Unit Test
어떤 함수(컴포넌트)를 직접 호출해 리턴값이 제대로 나왔는지를 확인하는 방법
자식 컴포넌트는 렌더링 하지 않고 테스트 하고자 하는 컴포넌트 자체만 렌더링 할 때 유용하다.
장: 테스트 하는 단위가 작아서 문제 발생 지점을 알기 편하고 빠름
단: 정확한 스타일을 렌더링하고 있는지 알기 어려움
-
통합 테스트 Snapshot Test
렌더링된 컴포넌트의 snapshot을 찍어 진행되는 테스트 방법
테스트 최초 진행시 컴포넌트의 snapshot을 저장해뒀다가, 이후 이와 비교해 컴포넌트의 마크업 및 스타일이 바뀌지 않았는지를 확인한다.
(Jest에서는 렌더링된 컴포넌트 마크업의 snapshot을 찍는다.)
테스트 통과 O ⇒ 컴포넌트의 모습은 바뀌지 않았다.
테스트 통과 X ⇒ 로직을 변경할 때 컴포넌트의 외관에 의도치 않은 영향을 주었다.
컴포넌트마다 최소 하나 이상의 Snapshot test를 작성해주는 것이 좋다.
(단, snapshot 자체의 유지보수가 어려워질 수 있으므로 남발하면 안 됨)
-
E2E 테스트 End to end Test
E2E(End to end) test는 최상위에서 진행되는 테스트
브라우저에 보여지고 있는 컴포넌트들을 사용자가 사용하듯 상호작용하는 방식
장: 각 컴포넌트들이 복합적으로 얽혀 일어날 수 있는 문제를 확인 가능
단: 속도가 느리고 디버깅이 어려움
🤔 JEST (자바스크립트 테스트 프레임워크)
What?
Jest는 페이스북에서 만들어진 테스팅 프레임워크로, 프론트와 더불어 최근엔 백에서도 사용됨.
Why?
Jest 이전에는 자바스크립트 코드를 테스트하라면 여러 가지 테스팅 라이브러리를 조합해서 사용해야 했다. 하지만 이제는 Jest는 라이브러리 하나만 설치하면, Test Runner와 Test Matcher 그리고 Test Mock까지 해결이 된다.
How?
test("테스트 설명", () => {
expect("검증 대상").toXxx("기대 결과");
});toXxx 부분에서 사용되는 함수 == Test Matcher
매처 Test Matcher
매처는 값이 특정 조건을 만족하는지 검증할 수 있는 일종의 집합이며,
jest에서는 expect() 함수를 사용하여 매처를 실행할 수 있다.
toBe 정확한 값을 유추해야 할 때 사용 (숫자나 문자와 같은 객체가 아닌 기본형값)
toEqual객체 일치여부를 확인할 때 사용
toHaveBeenCalled spyOn()함수와 같이 쓰이기도 한다. 함수가 호출 되었는지 검증
toHaveBeenCalledWith함수에 어떠한 인자가 넘어가 실행되었는지 함께 검증
toHaveBeenCalledTimes함수가 몇번 호출되었는지 정확하게 검증
toThrow특정 상황에서 에러가 발생하는지 테스트
