[Refactoring JavaScript] 테스트 1 - 왜 테스트 코드를 작성해야 하나, 테스트 방법

4년차 개발자인 나의 주요 관심사는 "어떻게 더 좋은 코드를 만들 것인가"이다.

 

그동안 여러 책과 구글의 도움을 받아 리팩터링을 해왔지만, 복습 및 내가 뭘 모르고 있는지 배우기 위해 <Refactoring JavaScript>를 읽기 시작했다. 

 

1,2 장에서는 리팩토링에 대해 설명하고 3장에는 테스팅에 대한 내용이 나온다.

 

왜 테스트를 해야하는가

3장 테스팅은 왜 테스트가 필요한지 설명하는 부분부터 나오는데, 나는 모든 이유에 격하게 공감하며 읽었다.

 

테스트 코드를 작성하지 않는 주된 이유로 "시간이 부족해서"가 가장 많은데, 사실 테스트 코드 작성하는데 익숙해진다면 테스트 코드 작성이 오래 걸려서 시간이 부족하다는 것은 핑계일 수밖에 없다. (물론 정말로 계속 데드라인을 쳐내야 하는 상황이라면 테스트 코드 작성에 익숙하지 않은 초심자가 업무 외 시간을 내서 익히는 게 장벽이 될 순 있겠다.)

 

하지만 큰 규모의 프로젝트를 다른 개발자와 협업하며 일해본 사람들은 이해하겠지만, 테스트 코드를 작성하는 게 장기적으로 코드 자신감 측면에서나 구현-테스트-배포 사이클 속도 향상 측면에서나 좋다.

 

그리고 아무리 QA 팀이 있어도 매번 모든 리스트를 수동으로 체크하며 테스트할 순 없다.

 

모든 코드 테스팅이 자동화될 순 없지만 자동화 가능한 부분이라면 당연히 자동화해야 한다.

 

---

다양한 테스트 방법

테스트 코드를 이야기할 때 보통 크게 두 가지로 나눠진다. unit test와 end-to-end test이다.

 

unit test는 말 그대로 작은 유닛(자바스크립트에서는 class, function, module, file 등이 될 수 있다)을 테스트하는 low-level을 의미하고, end-to-end는 이런 유닛들을 통합한 high-level 테스트를 의미한다.

 

하지만 모든 프로젝트 코드가 테스트 코드로 자동화될 수 있는 건 아니다.

 

따라서 수동으로 테스트를 하는 Manual Testing, 체크리스트를 작성하고 하나씩 수동으로 테스트하는 Documented Manual Testing이 있다.

 

또한 테스트는 보통 1. setup 2. assertion 3. teardown 단계로 나뉘는데 이미지나 비디오의 경우 코드로 assertion을 구현하는 것이 어려울 수 있다. 이런 경우에는 setup과 teardown은 자동화하고 assertion은 수동으로 체크하는 테스트인 Approval Test가 있다.

 

마지막으로 Nonfunctional Testing이 있는데, 이는 코드가 제대로 동작할 것이라는 자신감을 가지기 위해 테스트를 하는 위의 다른 테스트들과는 달리 performance, usability, accessibility 테스팅 등을 포함한다.

 

그 외에도 Features tests, Regression tests, Characterization test 등이 있다.

 

---

테스트는 어렵다. 또는 각기 다른 경력과 강점을 가진 개발자들과 협업할 때 이런 프로세스를 구축하는 것은 어려울 수 있다.

 

그래서 책에서는 도움이 될만한 Tool과 프로세스를 소개한다.

퀄리티에 대한 프로세스

- 코딩 기준과 스타일 가이드

: 에어비앤비, 구글 등 좋은 스타일 가이드를 쉽게 찾을 수 있다. 스타일 가이드를 처음 접한다면 그런 스타일 가이드를 참고하자.

 

- Developer Happiness Meeting

: 개발자들끼리 모여서 엔지니어링 퀄리티나 technical debt를 논의하는 회의를 말한다.

 

- 페어 프로그래밍

: 개발자 두 명이 짝을 지어 한 명은 코드를 작성하고 다른 한 명은 코드를 보는 식으로 진행된다.

 

- 코드 리뷰

: 코드 구현이 끝나면 리뷰어가 스타일 가이드 위반은 없는지, 버그나 테스트 coverage는 어떤지 확인하는 것이다.

 

- TDD (Test-Driven Development)

: 코드를 구현하기 전에 기능에 대한 테스트 코드를 먼저 작성하고 테스트를 통과하도록 코드를 구현하는 것을 의미한다. TDD는 좋은 테스트 coverage를 가진다는 점에서 많이 사용된다.

 

보통 red/green/refactor 사이클로 구성되며 테스트가 실패하면 red, 테스트 구현이 끝나면 green, 그다음에 refactor 하거나 cycle을 벗어나는 식이다.

---

4장에서 테스팅에 대해 더 알아보겠다.

---

출처

- Refactoring JavaScript [Book] by Evan Burchard