📧 후기
[인프런 밋업 #05 백엔드 테스트코드] 후기
date
Jul 29, 2024
slug
inflearn-meetup-05-review
author
status
Public
category
📧 후기
tags
후기
테스트코드
summary
지난 7월 24일, 인프런 [판교 퇴근길 밋업 #05 백엔드 테스트코드]에 당첨되어 판교 인프랩 오피스에 다녀왔다.
type
Post
thumbnail
지난 7월 24일, 인프런 [판교 퇴근길 밋업 #05 백엔드 테스트코드]에 당첨되어 판교 인프랩 오피스에 다녀왔다.
발표 내용이 유익했고, 밋업에 참여한 경험이 좋은 자극이 되었기에 이를 짧게나마 정리하여 글로 남겨보고자 한다.
밋업 제목에서 알 수 있듯이, 이번 밋업에서는 백엔드 개발에서의 테스트코드에 대해 희망편/현실편으로 나누어 총 2개의 발표 세션이 진행되었다.
- 첫번째 발표(희망편)에서는 1)테스트코드의 중요성(왜 테스트코드를 작성해야 하는가)과 2)어떻게 작성해야 하는지에 대해 다루었고,
- 두번째 발표(현실편)에서는 실무에서 테스트코드를 작성할 때 마주하게 되는 현실적 난관들과 이를 어떻게 극복할 수 있을지에 대한 고민이 담겨 있었다.
최근 진행 중인 프로젝트에서 테스트코드를 필수로 작성하는 것을 개발 컨벤션으로 두고 있긴 하지만, 과연 내가 작성한 테스트코드가 잘 짜여진 코드일지, 정말 이 테스트코드가 우리 서비스의 생산성 향상에 도움이 되고 있는 것인지에 대한 의문이 쌓여가던 시점이었다. 이에 대한 해답 내지는 방향성을 얻을 수 있을수도 있겠다는 기대감과 함께 두 발표 내용을 열심히 정리해 보았다!
#1 내 마음대로 되지 않는 테스트코드, 꼭 작성해야 할까? (희망편)
테스트 코드. 해야 한다, 해야 한다, 하지만 좀 처럼 쉽지 않죠. 개발 시간은 부족하고, 매번 도전하다 포기하고, 결국 이게 정말 필요한가? 라는 생각도 들곤 하죠. 그럼에도 우리는 테스트를 왜 작성해야할까요? 또 어떻게 작성하는게 좋은 테스트일까요? 함께 이야기 나눠보면 좋을 것 같아요.
🤷♀️ 왜 테스트코드를 작성해야 할까?
테스트코드를 작성해야 하는 이유는 무궁무진하다.. 그 중에서도 이번 발표에서는 테스트코드의 중요성을 아래 항목에 연관지어 강조했다.
생산성 향상: 테스트 자동화를 통해 반복적인 검증 작업을 줄이고, 코드를 더욱 빠르고 효율적으로 개발할 수 있다.
빠른 결함 인지: 코드 결함을 빠르게 찾아내어 문제를 즉각적으로 해결할 수 있다.
코드 이해도 향상: 검증된 최신 명세를 통해 코드의 역할을 쉽게 유추할 수 있다.
심리적 안정감: 테스트 코드는 코드의 품질에 대한 확신을 줌으로써 개발자에게 심리적 안정감을 제공한다.
그래 테스트코드 중요성 알지알지.. 그런데 그래서, 어떤 테스트코드가 좋은 코드인데?
🤷♀️ 어떤 테스트코드가 좋은 테스트코드일까?
- 빨라야 한다.
- 테스트코드는 자주, 그리고 빠르게 실행되어야 한다. 그래야 코드 결함의 인지 속도를 높이고 빠른 대응이 가능하다.
- 통합테스트에 불필요하게 포함된 영역을 단위테스트로 옮기자(ex. DB 연결이 불필요한 정책/알고리즘 관련 코드)
- 견고해야 한다.
- 테스트코드가 쉽게 깨지면 테스트코드에 대한 신뢰성이 떨어져 테스트 실패에 무감각해지고, 리팩토링이나 코드 변경에 소극적이게 된다.
- 보통 상세구현이 달라져서 테스트코드가 깨지는 경우가 많은데, 상세구현의 변경이 테스트코드의 실패를 불러오게 해선 안된다.
- Mocking을 사용한다면 상세구현이 드러나게 된다(호출되는 메소드의 노출 등). ⭐️
- 따라서 Mocking하지 않고 통합테스트로 진행하는 것이 더욱 적절할 때가 많다. ⭐️
- 코드 변경 감지
- 코드 변경시 이로 인해 발생할 잠재적 문제를 잘 알려줄 수 있어야 한다.
- 테스트가 많은 코드를 커버할 수 있어야 한다. 즉, 통합테스트의 비중을 늘리는 것이 좋다.
#2 내 마음대로 되지 않는 테스트코드, 어떻게 작성해야 할까? (현실편)
테스트 코드의 필요성은 모두 알고 있지만, 이를 실제로 작성하고 유지하는 데는 많은 어려움이 있습니다. 인프랩 팀에서 수천 개의 테스트 코드를 다루면서 겪은 문제들을 해결한 방법과 현실적인 고민에 대해서 이야기합니다.
🤷♀️ 1) 테스트코드 작성하기
- 테스트코드 작성 대상 정하기
- 각 class의 기능 명세를 정리하여 테스트 대상을 정한다.
- 작은 단위부터 테스트하기(단위테스트)
- 작은단위부터 테스트한다. 즉, 정책/알고리즘 등을 테스트하는 단위테스트부터 시작하자.
- 단위테스트는 비용이 적으니 최대한 많은 엣지케이스를 테스트하는 것이 좋다.
- 항상 성공하는 것들만 검증하는 테스트는 좋은 테스트코드가 아니다. 경계값, 특정 값의 존재유무를 테스트하여 실패를 감지하는 코드를 작성하자.
- 외부 의존성 관리하기 ⭐️⭐️⭐️
- 관리 의존성 → 실제 인스턴스를 사용
- 관리 의존성 : 애플리케이션을 통해서만 접근할 수 있는 외부 의존성, 따라서 제어 가능한 영역(ex. DB)
- 비관리 의존성 → Mocking
- 비관리 의존성 : 다른 애플리케이션이 접근할 수 있는 외부 의존성, 따라서 제어 불가능한 3rd party 의존성(ex. 외부 API, SMTP 등)
- 외부 의존성의 문제로 인해 우리 서비스 배포에 문제가 생겨선 안된다!
🤷♀️ 2) 테스트코드 작성 시간 확보하는 법 + 작성 속도 높이는 법
먼저 알아둘 것) 인프런은 TDD를 하지 않는다.
- 테스트코드 작성 시간 확보 ⏱️
- 70%(구현+테스트코드+구현+테스트코드+…)+30%(리팩토링)
- 구현과 테스트코드를 같이 하면, 구현하면서 놓친 부분을 빠르게 인지할 수 있고 실시간으로 코드 리팩토링이 가능하다!
- 테스트코드 작성 속도 향상 🏃♀️
- 선택과 집중
- 간단한 코드 영역보다는 domain, algorithm이 포함된 영역의 테코 작성을 더 우선시하라
- 외부에 의존하지 않는 순수함수 영역을 넓혀라
- coverage 집착하지 않기
- 커버리지가 낮은 건 경계해야 할 대상이지만, 커버리지 100%가 좋은 테스트코드인 것은 아님
- 발표자분의 팀은 cicd시 소나큐브 커버리지 70% 이상을 유지한다
- 테스트코드 다이어트
- 테코도 유지보수 비용이 든다. 더이상 사용하지 않는 TC, 테코에서만 호출하는 method는 삭제하자
두 발표를 관통하는 공통되는 내용이자, 두 분 모두 반복해서 강조하신 지점은 다음과 같다.
- 상세 구현이 드러날 수 있는 Mocking을 지양하고 통합테스트의 비중을 늘리되, 단위테스트만으로도 검증할 수 있는 테스트코드는 단위테스트 영역으로 분리하여 테스트코드의 속도를 향상시키자.
- 단위테스트 ↔ 통합테스트는 상호 보완적인 관계에 있기 때문에, 각 테스트의 장단점을 고려하여 상황에 맞게 적절히 범위를 나누고 적용하는 것이 중요하다.
이번 밋업을 통해 어떤 방향으로 테스트코드를 작성해야 할지 어렴풋이하나 알게 되어 정말 좋았다. 테스트코드의 중요성을 다시금 되새기는 것은 물론, 테스트코드를 작성하는 과정에서 중요하게 고려해야 할 점들을 되짚을 수 있었다.
현재 내가 작성하고 있는 테스트코드의 품질에 대해서도 생각해볼 수 있는 기회가 되었다. 테코 장인 팀원분의 훌륭한 지도가 있었기에bb 발표 내용과 크게 벗어나는 부분은 없어 보이지만, 내부적으로 단위테스트로 옮길 수 있는 부분은 없는지, 불필요한 모킹이 사용된 부분은 없는지 꼼꼼히 검토해보는 것이 좋을 것 같다.
이번 밋업은 내게 좋은 자극제가 되기도 했다. 각자 몸담고 있는 실무에서 다른 것도 아니라 무려 테스트코드를 더 잘 작성해보고자 하는 열정으로 밋업에 참여해주신 분들을 보며, 나 또한 더 나은 코드, 더 견고한 서비스를 개발하고 싶다는 의지가 불타올랐다. 동시에, 테스트코드를 작성하는 개발 문화를 가진 회사에 대한 갈망도 피어 올랐다. 테스트코드 작성이 개발 생산성을 향상시키고 높은 코드 품질을 유지하는 중요한 요소임을 알고 이를 실천하는 환경에서 일하고 싶다는 마음이 강해졌다.
아직은 천천히 배워가는 단계이지만, 언젠가 테스트코드를 통해 생산성이 향상되는 경험을 할 수 있길!
Jul 29, 2024