리팩토링 계기과정테스트 코드 작성단위, 통합 테스트E2E 테스트코드 컨벤션 및 기타 코드 리팩토링Github Actions 를 통한 CI/CD 파이프라인 구축 (feat. Vercel)테스트 친화적 코드 리팩토링참고
해당 포스트는 주관적인 내용이 많이 담겨 있습니다.
해당 블로그를 개발하고 운영한지 벌써 1년 이상 지났다.
처음에는 jekyll 을 통해서 블로그를 만들었지만 마음에 드는 디자인도 없었고, 마크 다운 작성 시 내가 작성한 글이 실제 화면에서 어떻게 보이는지에 대한 피드백도 없어 답답했었다.
그래서 이것 저것 찾아보다가 노션으로 블로그를 만들 수 있는 라이브러리를 찾게 되었고 노션 API 와 라이브러리를 통해 지금의 블로그를 만들게 되었다.
지금도 만족하면서 사용하고 있고, 여러 가지 추가 기능들을 도입하기 위해 계획하고 있다.
리팩토링 계기
개발을 완료한 이후 블로그에 대해서는 노션을 통해 포스트를 작성하는 작업 밖에 하지 않았다가 추가 기능을 도입하기 위해 오랜만에 코드를 살펴보는데 하나의 컴포넌트 내부에서 여러 개의 컴포넌트가 조건부 렌더링을 통해 복잡하게 렌더링 되어 코드 가독성이 떨어지거나 굳이 필요 없는 코드가 존재하는 등의 문제점을 발견하였고 이로 인해 리팩토링을 해야겠다는 생각이 들었다.
과정
테스트 코드 작성
테스트만을 위한 책은 아니지만, 읽고 있는 책 중에 ‘육각형 개발자’ 라는 책이 있다.
그 책에 리팩토링에 대한 내용이 있는데 그 중 인상 깊은 문구가 있었다.
리팩토링하기 전 테스트 코드를 작성하는 것이 기존 코드의 결과를 검증할 수 있기 때문에 안전하게 리팩토링 할 수 있다.
어떻게 보면 당연한 소리 아닌가 하겠지만 해당 문구를 읽고 예전에 내가 경험했던 고민들이 떠올랐다.
예전에 개인 프로젝트 리팩토링을 진행했을 때
"어디서부터 어떻게 손대야 하나"
"이 함수는 어떤 값을 반환하지?"
"이 부분을 변경했다가 다른 부분에서 이슈가 발생하면 어떡하지?"
이런 고민들을 했었는데 책의 문구가 과거의 이 고민들을 해결해 줄 수 있을 것 같다는 느낌이 들었다.
그리고 예전 회사 프로젝트에 유틸 함수에 대한 테스트 코드를 작성한 적이 있었는데 인수인계 문서 작성 시 테스트 코드 덕분에 코드 파악을 빠르게 할 수 있어서 문서화에 많은 도움을 받은 적이 있었다. 이러한 장점도 내 프로젝트에 적용하고 싶었다.
단위, 통합 테스트
Jest 와 React Testing Library 를 통해 컴포넌트와 함수에 대한 단위, 통합 테스트 코드를 작성할 계획이다.
요즘에는 vitest 도 많이 사용하는 것 같은데 이 부분은 추후에 직접 사용해 보고 Jest 와 장단점을 비교해서 도입 여부를 결정할 것 같다.
E2E 테스트
Playwright 를 통해 페이지에 대한 테스트 코드를 작성할 계획이다.
코드 컨벤션 및 기타 코드 리팩토링
테스트 코드를 작성했다면 작성하기 전과 비교했을 때 훨씬 더 안정적으로 리팩토링이 가능해 질 것이라고 생각하기 때문에 테스트 코드를 작성하고 리팩토링이 필요한 코드를 발견하면 바로바로 수정을 진행할 계획이다.
Github Actions 를 통한 CI/CD 파이프라인 구축 (feat. Vercel)
현재 vercel 을 통해 블로그를 배포하여 운영하고 있는데 배포 과정에서 코드에 대한 검증 과정이 포함되어 있지 않은 상태이다. 그래서 Github Actions 를 통해 내가 작성한 테스트 코드를 검증 과정으로 적용하여 검증 후 성공 시 배포가 이루어지게 파이프라인을 구축할 계획이다.
테스트 친화적 코드 리팩토링
테스트 코드를 작성하다 보면 내가 작성한 코드가 결합도가 강한 코드라는 것을 느낄 때가 생긴다.
이로 인해 테스트 코드 작성에 대한 복잡성 뿐만 아니라 실제 코드 사용 시에도 코드 파악이 어렵고 유연성이 떨어지겠다는 생각이 들어 기존 코드를 테스트하기 좋은 코드로 리팩토링할 계획이다.
참고
각각의 과정들에 대해서 해당 글에 작성하면 너무 길어질 것 같아 별도의 포스트를 통해 자세하게 다룰 예정이다.