Mong dev blog

0. 들어가며…지난 시간에는 테스트 코드를 관리하는 방법 중 하나로, “pre-push 단계에서 테스트 실패를 체크하는 방법”을 알아보았다. 이 방법의 경우, 코드 수정시 발생하는 오류를 테스트 검증으로 막을 수 있었다.하지만 서비스는 끊임없이 변화하고 개선된다. 이 상황에서 추가 기능의 테스트 코드가 작성되지 않는다면, 리뷰 단계에서 놓치기 쉽다. 그렇다면, 기존 소스 코드에 기능을 추가할 때 테스트 코드 를 어떻게 관리할 수 있을까?그 해답은 develop(베이스 브랜치)을 기준으로 수정한 파일에 한해 커버리지를 비교하는 방법이다.이 방법을 사용하면 기능을 추가한 뒤 해당 파일의 커버리지가 감소한 경우 PR 코멘트로 알려주고, 병합을 막을 수 있다.이번 글에서는 “테스트 코드를 관리하는 법” 시리즈의..

1. 들어가며올해 테스트 코드를 도입하면서 유틸뿐만 아니라 화면 단위의 파일까지도 테스트를 작성하기 시작했다. 처음에는 테스트 작성에 많은 시간이 소요되었지만, 기준이 잡히고 나니 점차 작성 속도가 빨라지는 것을 느꼈다.그러나 테스트 코드를 작성한 지 1~2달이 지났을 때, 전반적인 테스트 코드를 구동시킨 결과 몇 가지 문제점이 드러났다:리팩토링 및 버그 수정으로 인해 이미 삭제된 함수나 변수를 검증하려다 발생하는 오류.새로운 기능이 추가되었지만 테스트 코드 상 오류가 없어 검증되지 못한 케이스의 증가. 물론, 테스트 코드를 잘 작성하고 목표한 테스트 커버리지에 도달하는 건 중요하다. 하지만, 장기적인 관점에서 “테스트 코드의 관리”도 중요하다는 걸 깨달았다.그렇다고 매번 테스트 코드를 수동으로 확인한다..