드디어 당첨
어느새 세션 쫓아다니기가 취미가 되어버렸다. 취업도 못 한 나에게 시기상조라고 생각이 될 수 있지만, 먼저 시행착오를 겪은 분들의 생각과 느낀점들을 간접적으로 느끼며 문제 해결능력을 기를 수 있고, 개발 공부에 대한 권태나 무기력을 많이 상쇄시킬 수 있었다. 다른 개발자들도 나와 같은 마음인지 인프런에서 진행하는 세션들은 항상 경쟁이 치열했다. 항상 탈락 되었었는데 최근 테스트 코드를 학습하고 적용하는데에 어려움이 있던터라 이번 세션은 너무나 가고 싶었다. 이러한 마음이 잘 전달 되었는지, 당첨 소식을 들을 수 있었다!!
- 영롱한 선정 안내 메일...!!
세션 시작 전
퇴근길 교통을 생각해서 먼저 판교에 도착하여 카페에서 작업을 하고 이른 저녁을 먹었다. 세션중에 간단한 샌드위치와 음료가 준비되었다고 했는데, 내 위장은 간단한 샌드위치로 채울 수 없기에 든든하게 먹고 세션장에 입장했다. 간단한 본인인증을 하고 이름표와 에코백을 굿즈로 받았다. 그리고 간단한 샌드위치의 정체는 서브웨이였다. 편의점 샌드위치 정도 스케일을 생각했는데... 저녁 괜히 먼저 먹었다.
- 뭔가 손에 쥐어주니 이미 세션 만족도가 최대치다
- 서브웨이 야무지게 먹으면서 세션 기다리는 중
세션 시작
세션 연사분은 탐정토끼라는 닉네임으로 X에서 활발히 활동하시는 개발자 분이셨다. 소셜 미디어를 안하다 보니까 잘 몰랐는데 유명한 분이셨다
- 좋은 글들을 많이 적으시는 것 같으니 소셜 미디어를 하시는 분이라면 팔로우 해보시는 걸 추천
프론트엔드의 문제와 고민들
간단한 자기소개를 해주시고 바로 오늘의 주제 테스트 코드에 대해서 이야기를 시작하셨다. 먼저 프론트엔드의 테스트 코드 작성 필요성을 설명해주셨다.
- 디자인이 나오길 기다리고, 백엔드 API가 나오길 기다린다
- QA마다 기획을 오해하고 누락한 사실을 깨닫는다.
- 에러 핫픽스 하느라 기능 개발이 늦어진다.
- 공통 로직이나 디자인 시스템을 건드리면 옛 기능도 깨진다
- ⇒ 테스트하고 올리신 거 맞아요? 동료를 못 믿게 된다.
실무를 접하지 못한 나도 어느정도 공감이 가는 문제들이었다. 몇 번의 팀 프로젝트를 진행하면서 프론트엔드 파트는 다른 파트들의 작업이 어느정도 완성이 되어야 작업을 시작할 수 있기에 항상 기다리다가 마지막에는 시간에 쫓긴다. 그리고 시각화 디테일이 중요한 파트인데, 같은 미팅, 회의를 진행했음에도 서로 생각하는 바가 다른 경험을 매우 많이 경험했다. 그렇게 몇 번의 마찰을 겪게되면 불화가 생기는 경우도 더러 봤다.
다 먹고 살자고 하는건데, 얼굴 붉히면서 할 필요 없지 않은가. 그래서 가장 적절한 대안은 바로 테스트 코드를 작성해서 서로의 목표를 구체화 시키는게 중요하다. 여기서 중요한 전제는 테스트 코드가 꼭 믿음직한 테스트 코드여야 한다는 것이다.
하지만 현실은...
계획대로 인생이 살아지면 인생은 참 아름다울텐데 현실은 내가 컨트롤 할 수 없는 부분이 너무 많다. 일단, 테스트 코드를 작성하는 것 자체가 비용이 발생해서 기능 개발 일정에 차질이 생길 수 있다. 또한, 나같은 쪼렙 개발자들은 러닝커브도 존재하기에 비용은 더 커질 수 밖에 없다. 최근에 시작한 팀 프로젝트에서 패기롭게 '테스트 코드 작성해보시죠!', '우리도 TDD 해보시죠! 제안했다가 일주일도 못가서 단점이 더욱 부각되어 팀원을 설득 시키지 못한 경험이 있다. 그 외에 3줄짜리 코드를 테스트하기위해 테스트 코드가 20줄 이상 작성해야 한다던지, 총 테스트 소요 시간이 너무 오래걸려 안하게 된다던지... 와 같은 아찔한 케이스들을 소개해줘서 더욱 몰입이 되었다.
그래서 대안은?
우선 테스트 코드를 왜 작성해야 하는지 다시 한 번 생각해볼 필요가 있다. 요즘 트렌드라? 쓰면 좋대서? 문제를 해결해 줄 것 같아서? 등 나같이 막연하게 테스트 코드를 접근하면 안된다. 테스트는 어디까지나 테스트일 뿐이고 이 행위는 결국 개발을 효율적이고 빠르게 해주는데에 포커싱이 되어야 하는데, 테스트 코드를 작성하기 위해 테스트 코드를 작성하는 주객전도가 되면 안된다. 또한, 지금 당장 도움이 되는 테스트를 작성해 후에 시간을 벌어주는 그런 선순환적인 구조를 덧붙여서 설명해주셨다.
컴포넌트 주도 개발
이전에 프론트엔드 테스트가 힘들었던 것은 페이지 단위로 테스트를 했기 때문에 시간도 오래걸리고 효과적이지 못했던 것이라고 설명해주셨다. 프론트엔드 프레임워크들은 모두 컴포넌트를 사용해 조립하는 컴포넌트 주도 개발을 밀어주고 있기 때문에 이에 맞게 테스트를 진행해야 한다.
스토리북
지금까지 설명한 프론트엔드 테스트를 효과적으로 하기 부합한 툴은 스토리북이다. 스토리북은
각 컴포넌트들의 상태를 한꺼번에 효과적으로 보여주고 이를 통해 각 파트들의 이해관계를 좀 더 시각적으로 빠르게 테스트 할 수 있어 효과적이다. 열심히 컴포넌트로 스타일링까지 마쳤는데, 데이터를 패칭하면서 디자인이 바뀌는 경우 혹은 배포 할 때 스타일링이 내 예상과 다르게 적용되는 경우가 허다했다. 그럼 다시 왜 이런 현상이 발생했는지 파고 들어야 하는데 운이 나쁘면 하루종일 들여다 봐야 하는 경우도 있었다. 이러한 경우의 수를 스토리북으로 미리 알았다면? 좀 더 개발일정에 차질이 덜 있지 않았을까? 하는 아쉬움이 생겼다.
프론트 테스트 베스트 프랙티스
시나리오 작성
스토리북만 쓴다고 만사 OK면 좋겠지만, 인생은 그리 호락호락하지 않다. 테스트보다 더 중요한것은 시나리오 작성이라고 설명해주셨다. 시나리오를 생각하고 그에 맞는 테스트를 작성하는 순으로 프로세스를 이어가야 효율적인 테스트 코드가 될 것이라고 말씀해주셨다. 다시 생각해보니, 순전히 테스트를 하는 행위를 위해 테스트 코드를 작성했더니 동기부여도 전혀 없고 개발에 크게 도움이 되지 않았던 것 같다.
웹 접근성 공부하기
테스트를 위해 한 요소를 찾아야 할 때 일일히 찾아다니려면 너무 번거로운데 접근성을 이용해 매우 간편하게 요소를 찾을 수 있다.
<button aria-label="구매하기"></button>getByRole("button", { name: "구매하기" })이런식으로 버튼의 요소의 aria-label을 검색해서 바로 특정지을 수 있다.
의존성과 결합도에 대해 잘 생각하자
겨우 코드 3줄 테스트하려고 모킹만 수십줄을 해야해요 - X
- 의존성 설계를 잘 해야하는 것을, 몸이 고생해서 넘어가게 함
- 여러분의 동료가 테스트를 싫어하고 증오하게 만듦
실제 의존성, 가짜 구현체 주입, 실용적인 모킹 - O
- jsdom 대신 vitest browser mode를 사용
- useQuery를 모킹하는 대신 그저 prop으로 데이터를 넘기기
- 개인적으로 vi.mock, vi.fn vi.spyOn은 한 줄도 쓰지 않음
아직 경험해보지 못한 내용들이라 이해가 잘 안되지만, 중요한 것은 결국 실용적이고 본질적인 개발에 도움을 주는 테스팅을 해야한다는 것이 이번 세션의 주제임을 알 수 있다.
후기
인프콘, 퇴근길 밋업이 경쟁률이 왜 치열한지 알 수 있는 세션이었다. 무료라기에는 너무 알찬 세션이었다. 후에 네트워킹 시간도 있었는데 개인 일정이 있어 참석하지 못했다. 다음에도 뽑힐지는 모르겠지만, 네트워킹 꼭 해보고 싶다!
