Jest 왜 쓰지?: 테스팅 라이브러리를 쓰는 본질적인 이유
우리가 보통 이해하고 있는 테스팅 라이브러리를 쓰는 이유는, 단위테스트를 하기 위함입니다. 모듈, 함수에 특정 값을 대입 했을 때 기대한 결과값이 도출되는지, 렌더링된 화면에 내가 원하는 요소, 콘텐츠 등이 들어있는지 등을 확인하기 위해서이죠.
expect().toBe() 형태로 특정 값이 원하는 바가 되는지 확인하는 것이 우리 모두 당연히 알고있는 기본적인 목적입니다.
그런데 어느날, 함수를 호출하여 화면에 나오는 값과 같은지 테스팅 코드를 작성하는 업무를 했는데요, 업무를 하다가 의문점이 생겼습니다.
화면에 나오는 함수와 테스팅 하는 함수는 같은 함수를 사용하고 있는데, 당연히 같은 함수를 사용하기 때문에 화면에 나오는 값과 같은 값이 계속 나와 통과하지 않을까? 이런 테스팅 소스를 작성하는 이유는 무엇이지? 하고요.
이러한 테스팅의 키 포인트는 “기댓값의 스냅샷”에 있습니다. 내가 열심히 작업하여 나온 28 이라는 올바른 값은 엄청 중요한 값일 수도 있습니다. 앞으로 서비스를 운영할 때에도 계속 유지돼야 하는 중요한 값일 수도 있습니다. 그런데 규모가 커지면서 이 28이라는 값을 미처 추적하여 관리하지 못해 28이라는 값이 18로 변하는 상황이 생긴다면? 커다란 문제를 야기할 수 있는 것입니다.
그렇습니다. 저는 ‘값’을 보지 않았고, 함수의 실행만을 봐 왔던 것입니다. 그럼 이제 그림을 이렇게 정리해야 합니다.
한 번 서비스 개발에 성공하여 28 이라는 값이 나왔습니다. 앞으로 서비스를 지속 할 때에도 28 이라는 값은 계속 나와야 합니다. 그 ‘성공값’을 우리는 테스팅 소스에 ‘스냅샷을 기록한다’는 의미로 저장하는 것입니다. 그러면, 프로그램 수정, 함수 로직 수정에 따른 예상치 못한 변화를 감지하여 서비스 유지보수에 탁월한 효과를 가져올 것입니다.
여러 기업의 채용공고를 보면, 테스팅 라이브러리 사용 경험이 거의 필수로 들어가 있는 것을 볼 수 있습니다. 개발하는 서비스 규모가 작으면 할 필요가 없지만, 그래도 우리모두 서비스 개발할 때 작은 서비스라도 나름의 테스팅 라이브러리를 작성하는 습관을 들여봅시다!
