04 : 테스트 구축하기




자가 테스트 코드의 가치

  • 모든 테스트를 완전히 자동화하고, 그 결과까지 스스로 검사하게 만들자.
  • 테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는데 걸리는 시간을 대폭 줄여준다.


테스트 구축하기

  • 실패해야 할 상황에서는 반드시 실패하게 만들자.
  • 자주 테스트하자. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자


테스트 추가하기

  • 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는게 낫다.


경계 조건 검사하기

  • 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자.
  • 어차피 모든 버그를 잡아낼 수는 없다고 생각하여 테스트를 작성하지 않는다면, 대다수의 버그를 잡을 수 있는 기회를 날리는 셈이다.


나의 회고🤔

앞선 장에서 느꼈듯이, 저자는 리팩터링과 테스트는 분리할 수 없는 필수 요소임을 강조한다.

테스트의 중요성, 활용방안에 대해 적어도 10번은 들으니, 이제 나도 테스트의 중요성은 백번 천번 이해하게 됐다.😭👍

확실히 테스트를 하면서 리팩터링을 하면, 리팩터링 시 예기치 못한 변경을 막기 좋아보인다.

또한 내가 손으로 일일히 console.log를 찍어가며 테스트하는 것보다는 속도가 훨씬 향상될 것이다. (1번도 빠를텐데 그 수가 매우 반복된다면…?

(A, B, C 함수가 서로를 참조할 때, 내가 A를 수정하면 B, C까지 직접 console.log를 찍는 것보다는….)

다만 아직 TDD에 능숙하지 않다보니, 유닛 테스트에서, 도대체 어떤 함수만 테스트를 작성해야 하는지, 한다면 어느정도의 엣지 케이스를 둬야하는지 가 분명하지가 않아서 테스트 구축하는데 시간이 얼마나 들지가 예상이 안되서 걱정이 되긴 한다.

하지만 테스트의 중요성과 그 이점은 이제 분명하게 이해하였고, 앞으로는 TDD로 개발을 해봐야겠다.

(이 챕터를 읽고, 뭅스터 서버를 리팩터링 하기 위해 간단한 프로토타입 서버를 만들어 TDD를 적용했는데, 이에 관한 내용은 다른 포스팅에서 자세히 다뤄보겠다.)


러버덕🏃‍♂️

  • 테스트 도구로 무엇이 있을까?
  • 유닛 테스트용 : jest, mocha
  • FE EtoE 테스트용 : cypress