프런트엔드 개발을 위한 테스트 입문: 챕터 1 (항해99 사전스터디)
두 번째 사전 스터디 그룹은 프론트엔드 테스팅입니다! 🥳
다양한 경력의 팀원분들과 하게되었는데 다들 친근하게 으쌰으쌰해서 할 수 있는 분위기인거 같아서 다행인거 같습니다.
사실 팀원분들과 마찬가지로 테스팅 코드를 써본적은 없고, 프론트에서 쓰이는지도 사실 몰랐는데, 한층 더 좋은 코드, 개발을 위해선 필요하지 않을까 싶어서 참여를 했고요, 타입스크립트랑 마찬가지로 교재를 사서 시작을 해보겠습니다. (흑흑 교보문고에서 하드카피 사고 싶습니다.. ㅠㅠ ebook으로 만족해야하는 😭)
이 시리즈는 프론트엔드 개발을 위한 테스트 입문을 읽고, 발표를 준비한다는 마인드로 노트랑 독후감 같은걸 적어볼꺼같습니다.
챕터 1: 테스트 목적과 장애물
일단 다룰 테스트는 총 5가지
함수 단위 테스트
테스트코드를 작성하면서 신뢰할 수 있는 함수(테스트 코드에 의해 검증된 함수)를 만들다 보면, 코드에서 발생할 수 있는 문제를 빠르게 발견할 수 있답니다. 그래서 함수 마다 단위테스트를 작성하며, 테스트 자동화 방법도 배워본다고 합니다.
UI 컴포넌트와 Unit(단위) 테스트
함수로 만든 UI 컴포넌트일수록 단위 테스트가 쉽단다, 요즘은 웹 접근성 품질까지 단위 테스트로 검증할 수 있다. 가상의 폼을 대상으로 코드를 작성하며 테스팅 하는 방법을 배워본답니다.
UI 컴포넌트와 통합 테스트
UI 컴포넌트는 데이터를 화면에 그리는 일 외에도 많이 하는데 예로는 input하면 asynchronous 처리를 하고, 비동기 응답이 오면 화면을 갱신한다. 통합 테스트는 이와 같은 외부 요인을 포함한 테스트이다. Mock 서버를 통합 테스트에서 활용하는 법을 배운다고 합니다.
UI 컴포넌트와 시각적 회귀 테스트
바뀐거 눈으로 확인.
E2E 테스트
headless browser(GUI 없는 브라우저)로 E2E Test 진행하면, 실제 에플리케이션에 가까운 테스트가 가능, 브라우저 고유 API를 사용하거나, 화면 간 테스트가 필요할때 적합하다고 한다. 실제 application은 DB 서버에 접속 혹은 외부 스토리지 서버에 접속하지만, E2E는 가깝게 상황을 재현해서 더욱 광범위한 테스트를 실시한다.
테스트 작성 이유
이제 제일 중요한걸 알아보겠습니다
왜 테스트 코드를 작성해야하는가?사업의 신뢰성
에 영향이 가기때문. 버그많은 서비스는 불편을 넘어서 이미지 추락을 초래한다 그렇기에 조기에 버그를 찾아, 많은 시간과 비용을 세이브해준다 BFF개발에도 요즘 프론트 개발자들이 참여를 한다고 한다 (authentication, authorization), 이런데 테스트코드 작성을 습관화하면, 이런 보안같은 핵심기능에서 나올수 있는 버그를 사전에 발견할 수 있다.
UI나 시스템의 버그는 서비스의 이미지와 직결한다
반복적으로 써야 하는 코드를 공통으로 사용할 수 있는 모듈로 만드는 리팩토링이 필요한데, 테스트 코드가 없으면 이미 구현에서 손 땐것에 문제가 생길지도 모른다는 불안감에 리팩터링을 시작하기 두렵다 (정곡 찔렷다..) 그래서 test code를 작성하면 문제가 생겼는지 반복적으로 확인할 수 있어 안정감을 느끼게 해준다고 한다.
테스트는 지속적인 리팩터링을 돕는다.
코드 수정은 새로운 기능 개발때만 되는것이 아니다, 사용하는 라이브러리에 업데이트가 있을때도 해야 할 수 있다 (진짜 짜증남). Dependabot을 사용하면 자동으로 취약성 검사 해줘서 PR해주지만, 모든걸 걸러낼수는 없기에 조심해야한다.
코드 품질 향상마이너 업데이트는 테스트를 통과하면 merge할 수있다라는 원칙을 세우자
에도 큰 도움을 준다. 해당 코드의 테스트 작성이 어렵다면, 해당 코드가 너무 많은 일을 한다는 반증일 수 있어서, 더 작은 부분으로 나눌 수 있는지 재검토를 해 코드 품질을 높일 수 있다.
웹 접근성을 높이는 데에도 기여한다. Web accessibility (신체적, 정신적 특성에 차이없이 모두 동등하게 정보에 접근할 수 있어야 한다라는 개념) UI 컴포넌트는 테스트 시 웹 접근성에서 유래한 API로 테스트 대상을 선택할 때가 많다고 한다, 그래서 접근성을 지키지 않으면 원하는 테스트 대상을 편하게 얻지 못한다. 그래서 테스트 코드이 있으면 다른 보조 기기 사용자들에게도 콘텐츠가 인식될 수 있는지 알 수 있다고 한다.
그리고 생각했던 거지만, 테스트 코드를 같이 구현 코드 개발과 작성하면 그 과정에서 지속적으로 구현 코드를 반추하게 됨으로 코드 품질이 향상된다고 한다.
테스트 코드는 글로 작성된 문서보다도 우수한 사양서이다
팀 단위 개발에서 중요한 커뮤니케이션, 온보딩, 협업에는 많은 시간이 필요하다, 그럴때, 코드외 주석, 사양서같은 걸 남기기도 하는데 테스트 코드도 그중 하나로 쓰일 수 있다.
각 테스트는 제목이 있어서 이 코드가 어떤 기능을 제공하고, 어떤 방식으로 작동하는지, 해야하는지 알 수 있다. 테스트를 통과했다면, 사양서대로 구현되어있다고 예상 가능하다 (그래도 가끔 제목과 테스트 내용에 차이가 있을 수 있으니 조심)
Continous Integration (지속적 통합)을 통과한 후 리뷰를 요청하는 규칙이 있다면 리뷰와 수정을 거듭하는 시간도 줄일 수 있다.
테스트 자동화는 회귀 테스트(Regression test)를 줄이는 최적의 방법이다. (이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법)
물론 작게 모듈을 나누면 책임도 줄어들고 테스트도 쉬워지지만, 모듈이 많아지면, 다시 조합하는 과정에서 모듈간 의존 관계가 생기고, 의존 중인 모듈이 변경 됐을 때 미치는 영향을 검증하고자 자주 regression test를 해야하게 된다.. 
진짜 짜증나는 거.
단위 테스트가 있어도. 시각적 결과물에는 회귀 테스트가 필요하다 (다 섞어서 하는게 좋다는 계시인가)
장벽
라이브러리의 공식 문서를 보며 구현하는게 어려운것 처럼, 테스트코드도 작성된 코드를 참고하는것이 효과적이다 작성할 시간이 없을 수도 있다, 개발 속도가 느려질 수 있기에 충분한 시간이 필요하다. 프로젝트 UI를 갈아엎었던적이 있다면, 테스트코드의 존재 유무에 따라 속도가 엄청 차이날 수 있다.
장기적인 관점에서 보면, 시간이 절약된다. 팀원들 설득해서 테스트코드 써보자 ㅎㅎ