항해 플러스 프론트엔드 코스란?
1~4년 차 주니어 프론트엔드 개발자들이 모여 매주 토요일마다 오프라인 모임, 코드 리뷰를 진행하고
평일에 한 번씩 멘토링을 진행하면서 주니어 개발자들이 성장할 수 있는 환경을 제공해 주는 코스입니다.
이번 항해 플러스 7주 차에선 테스트 코드에 대해서 배웠습니다.
현재 현업에서 테스트 코드를 필수로 작성하고 있어서 테스트 코드 작성법에 적응하였지만,
불과 1년 전 사이드 프로젝트할 때에는 테스트 코드에 대한 진입 장벽이 있었습니다.
왜 테스트 코드가 어렵게 느껴지는지, 막상 작성해 보니 어떤지 7주 차 후기를 통해 풀어보려 합니다.
테스트 코드와의 첫 만남
저는 테스트 코드를 처음 적용해 본 것은 제가 원해서가 아니라, 현재 다니고 있는 회사의 과제를 수행하기 위해서 9개월 전에 처음 테스트 코드에 대해 배웠습니다.
이때 테스트 코드 80%는 전부 Chat-GPT가 작성해 줄 정도로 단기간에 테스트 코드 작성법을 익히기 어려웠습니다.
Q: 왜 어려울까?
“왜 어려웠을까?” 그때 기억을 되짚어 본다면 어떤 컴포넌트를 테스트하는지, 이 부분을 이렇게 테스트하고 싶은데 어떤 API를 사용하여 코드를 구현할 수 있는지를 몰랐기 때문에 어렵다고 느껴졌던 것 같아요.
- 어떤 부분을 테스트해야 할지 몰라서
- 테스트할 부분을 찾아도, 어떻게 구현해야 할지 몰라서
A: 어려운 게 아니라 생소해서 그런 걸 수 있어요.
항해 플러스 프론트엔드 코스 멘토님께서는 것처럼 테스트 코드에 대한 작성법이 어렵다는 질문이 들어오면 다음과 같이 답변하셨습니다.
테스트 코드가 어려운 이유는 생소해서 그런 거예요.
저는 6개월 정도 회사에서 테스트 코드 작성 경험을 해보면서 해당 답변에 정말 큰 공감이 되었습니다. 테스트 코드를 처음 작성해 보면서 테스트 코드가 어렵다고 느꼈던 인식은 생소해서 그런 게 아닐까 싶습니다.
막상 테스트 코드가 어렵지 않은 이유
Q: 멘토님께서 테스트 작성 속도가 확연하게 늘었다 생각드신 적이 있으실까요?
A: 새로운 테스트 코드 패턴이 없다고 느껴질 때 테스트 코드에 대한 어려움이 사라진 것 같습니다.
패턴이 반복되었을 때 "아 이 상황에서는 이 패턴을 쓰면 되겠구나~" 라는 게 눈에 보이게 되었습니다.
이게 익숙해지려면 그만큼 테스트 코드를 많이 작성해 보는 게 좋습니다.
위 Q&A 내용에서 언급한 것처럼 막상 테스트 코드가 어렵지 않은 이유는 “패턴이 반복”되기 때문입니다.
9개월 전 과제를 수행하기 위해 Chat-GPT가 작성해 준 테스트 코드 최근에 보았습니다.
놀랍게도 현재 현업에서 작성하던 패턴과 크게 달라진 점이 없습니다.
제가 생각하기엔 아래와 같은 패턴이 반복됩니다.
- 유틸 함수
- 함수의 인자가 들어오면, 기댓값이 반환되는지
- 컴포넌트 단위/통합 테스트
- 요소(element)를 가져오고 →
- 사용자 이벤트가 실행되고 →
- 화면이 바뀌는지
- 요소가 화면에서 사라지는지
- 새로운 요소가 화면에서 추가되는지
- 요소가 이전 상태와 변경되었는지
- 요소가 화면에 노출되는지
- 화면이 바뀌는지
- 사용자 이벤트가 실행되고 →
- 요소(element)를 가져오고 →
컴포넌트의 단위/통합 테스트에 대해서 진입장벽이 높을 것으로 생각하는데, 사실상 기대하는 결괏값 패턴만 다르고, 요소를 가져온 뒤 → 사용자 이벤트가 호출되면 → 이 순서는 크게 달라지지 않습니다.
사실상 프론트엔드에서 테스트를 하는 이유는 웹에서 사용자의 인터렉션(이벤트)에 맞게 기능이 잘 실행되는지를 검증하기 때문에 패턴이 유사할 수밖에 없다고 생각됩니다.
테스트 코드 작성 경험이 중요한 이유
테스트 코드 작성 경험이 중요한 이유가 무엇일까요?
테스트 코드 작성 “경험”이 중요한 이유는 작성해 본 경험이 있어야 테스트 코드에 대한 색안경 없이 의견을 제시할 수 있기 때문입니다.
제가 이전에 사이드 프로젝트를 진행하였을 때 한 팀원이 이렇게 제안하였습니다.
팀원: 너가 담당한 성적 계산 부분, 일일이 테스트하기 어렵지 않아? 테스트 코드를 도입해 보는 게 어때?
나: 아… 테스트 코드 어려울 것 같아서, 잘 모르는데… 지금 테스트 코드 작성할 시간이 없기도 하고, 손으로 테스트하는 게 편해.
제가 개발한 기능은 성적을 입력하고 계산하는 기능으로, 주요 비지니스 로직이 포함되어 있습니다.
입력한 성적의 결과가 올바르게 노출되는지 테스트하기 위해서는 아래 사진처럼 모든 select의 점수를 선택해야 결과를 확인할 수 있었습니다.
실제로 QA 하면서 일일이 select를 선택해서 코드를 검증하게 되었습니다.
지금 되돌아보면 QA 시간이 엄청 번거롭고 더 오래 걸린 것 같습니다.
테스트 코드 작성 경험이 있었다면?
이러한 상황에서 테스트 코드 작성 “경험”이라도 있었다면, 위에서 친구의 제안에 논리적으로 대답할 수 있었을 것 같습니다.
제가 여기서 전하고 싶은 의도는 테스트 코드가 무조건 좋다기보다는 작성 경험이라도 있어야,
다음에 현업에서, 사이드 프로젝트에서 도입하자는 제안이 온다면 경험을 바탕으로 의견을 전달할 수 있기 때문입니다.
- 테스트 코드 작성 경험에 대해서 긍정적인 경우
팀원: 네가 담당한 성적 계산 부분, 일일이 테스트하기 어렵지 않아? 테스트 코드를 도입해 보는 게 어때?
나: 이전에 테스트 코드를 작성해 본 경험이 있었는데, 리팩토링할 때나 복잡한 비지니스 로직을 검증할 때 좋은 것 같았어. 너 말대로 현재 컴포넌트라도 테스트 코드를 통해 검증해야겠다!
- 테스트 코드 작성 경험에 대해서 부정적인 경우 (현재 프로젝트와 알맞지 않다고 생각되는 경우)
팀원: 네가 담당한 성적 계산 부분, 일일이 테스트하기 어렵지 않아? 테스트 코드를 도입해 보는 게 어때?
나: 이전에 테스트 코드를 작성해 본 경험이 있었는데, 현재 프로젝트에서는 불필요한 것 같아.
이 서비스는 일회성 서비스이고, 추후 유지보수가 필요 없는 1인 프로젝트이기 때문에 테스트 코드까지 도입한다면 유지 보수하게 되는 코드가 늘어날 것 같아서 도입하지 않아도 될 것 같아.
테스트 코드가 불필요하다고 생각할 수 있습니다.
하지만 그 생각은 작성을 해봤다는 경험이 있어야 하고, 논리적으로 설명할 수 있어야 합니다.
현업에서의 테스트 코드
왜 테스트 코드가 어려운지, 테스트 코드 경험이 왜 중요한지 다뤄보았으니, 제가 현업에서 테스트 코드를 작성하면서 느꼈던 장단점을 작성해 보려 합니다.
장점
1. 내가 작성한 코드에 대한 안정감
멘토님께서는 테스트 코드를 통해서 결정적인 버그를 막은 건 10가지밖에 안 된다고 하셨습니다.
하지만 생각하지 못한 엣지 케이스 외에는 요구사항에 맞게 테스트 코드를 작성하기 때문에 작성한 코드가 잘 동작할 것이라는 안정감을 얻을 수 있습니다.
2. 테스트 검증(QA) 시간을 단축시켜 → 리뷰 시간 단축
현재 제가 진행하고 있는 사이드 프로젝트에는 테스트 코드를 작성하고 있지 않습니다.
팀원이 작성한 코드만 보고, 잘 동작할 것이라고 보장할 수 없기 때문에 직접 브랜치에 pull을 받아 로컬에서 테스트를 해보게 됩니다.
이게 자잘한 코드라면 상관없겠지만, 중요한 큰 기능이라면 일일이 검증하게 되어 리뷰 시간이 길어지게 됩니다. 테스트 코드를 작성한다면 테스트 검증을 코드로 해주기 때문에 기능적인 부분에서 크게 리뷰하는 부분이 줄어들어 시간을 단축할 수 있다고 생각합니다.
3. 리팩토링
(feat. 테스트 코드가 없다면 리팩토링을 할 수 없다는 짤)
리팩토링은 기능의 동작은 유지하되, 코드의 가독성/유지보수성을 개선하는 방법이기 때문에 테스트 코드를 작성하면 리팩토링에 대한 안정성이 올라갑니다.
내부 코드는 변경되었더라고, 요구사항이 동일하기 때문에 내가 작성한 테스트 코드는 통과해야 하기 합니다. 그래서 테스트 코드를 작성한다면, 리팩토링하면서 기능이 잘못되는 이슈를 줄여줄 수 있습니다.
단점
1. 유지 보수해야 하는 코드가 늘어남 → 당연하게도 작업 시간이 늘어남
테스트 코드도 엄연히 “코드”이기 때문에 유지보수가 필요합니다.
요구사항이 아예 바뀌게 된다면 구현체와 테스트 코드를 전부 수정해야 하므로 유지 보수해야 할 코드가 늘어나게 되죠.
단점을 보완한 방법
유지 보수해야 할 코드가 늘어나면서 작업시간이 늘어나는 게 테스트 코드의 단점이라고 생각하는데요.
저희 회사에서 테스트 코드 작성 단계까지 기능 구현의 일부로 보기 때문에, 작업기간을 정할 때 테스트 코드까지 고려하여 일정을 공유합니다.
이렇게 작업시간이 2배로 늘어나지 않도록 일정 조율을 하면서 테스트 코드가 블로킹 되지 않도록 최대한 보완하도록 하였습니다.
테스트 코드 작성을 규칙으로 정하면 작성 경험이 쌓이면서 패턴이 눈에 들어오게 됩니다.
작성법에 익숙해지면 테스트 코드 때문에 작업이 크게 지연되지 않는 것 같습니다.
그래서 하고싶은 말은?
테스트 코드가 어렵게 느껴지는 이유를 정리하자면 "생소함" 때문입니다.
프론트엔드 개발에서는 복잡한 비즈니스 로직보다 화면 구현에 초점을 맞추기 때문에, 화면을 가상으로 그리고 가져오며 특정 로직을 검증하는 테스트 코드가 생소하게 느껴질 수밖에 없습니다.
하지만 중요한 점은 테스트 코드를 작성해보는 “경험”은 필요하다는 것입니다.
어려워 보이거나 생소하다는 이유로 테스트 코드 작성을 피한다면, 결국 한계에 부딪히게 됩니다.
테스트 코드를 작성하는 것이 귀찮아 보이고, 어려워 보여서 색안경을 써버리게 되면, 계속해서 도전하지 못할 것입니다.
테스트 코드가 귀찮고, 어려워서 도입하지 않는게 아니라 “왜” 도입을 하지 않는 것인지 경험을 통해서 알아가시는걸 추천드립니다.
또 강조하고 싶은 부분은 테스트 코드는 생소하지만, 크게 어렵지 않습니다.
테스트 코드를 규칙적으로 작성하면서 경험을 쌓으면, 패턴이 눈에 들어오고 작성법에 익숙해지면서 작업이 크게 지연되지 않습니다. 결국, 이는 개발 과정의 효율성을 높이고, 더 안정적이고 신뢰할 수 있는 소프트웨어를 만드는 데 기여할 것입니다.
마무리 & 한 줄 후기
이렇게 항해 플러스 프론트엔드 7주 차에 배운 테스트 코드 내용을 다루어 보았습니다.
항해 플러스 내용보다는 제 개인적인 테스트 코드 견해에 대해 주절주절 작성한 것 같네요 ㅎㅎ
아무튼 항해 플러스 코스를 신청하신 분, 고민 중이신 분들이라면 꼭 코스 시작하기 이전에 테스트 코드를 미리 공부하시는 걸 추천해 드립니다.
과제 진행 방식이 과제 요구사항에 대한 구현체를 작성하고, 과제 채점을 테스트 코드 성공 여부로 판별하기 때문에 테스트 코드에 대한 사전지식이 있어야 과제를 풀이하시는 데 도움이 되기 때문입니!
이번 7주차에서는 테스트에도 어떠한 종류가 있는지 알게되었고, 어떤 상황에서 어떤 테스트 방식을 사용해야하는지 고민해보게 되는 경험을 할 수 있었습니다.
긴 글 읽어주셔서 감사합니다!
⭐️ 항해 플러스 프론트엔드 코스 4기 모집
제가 현재 참여하고 있는 항해 플러스 프론트엔드 코스가 4기를 모집하고 있다고 하여 공유드립니다!
10월 24일까지 신청하시면 얼리버드 혜택으로 약 50% 할인을 받으실 수 있습니다.
또한 추천인 제도로 [추천인] 코드에 “zmK2OE”를 입력하시면 20만 원 추가 할인 혜택이 있으니
관심 있으신 분들은 항해 플러스 공식 홈페이지에서 신청하시면 됩니다 :)
저의 후기 글을 보시고 항해 플러스 프론트엔드 코스 관련해서 궁금한 사항이 있으시다면 링크드인 메시지 또는 이메일 yoosioff@gmail.com으로 편하게 연락주세요.
