입사한지 두달정도 되어갈 무렵, 정말 큰일이 있었다. 회사 서비스에는 주문시 보증금을 포인트로 반환해주는 기능이 있었는데, 해당 보증금이 약 한달정도 적절하게 반환되지 않는 문제가 있었다. 서로 얽혀있는 테이블이 많이 있어서 한번에 쿼리로 변경하기도 어려웠다. 그래서 서비스 이전 후 데이터부터 약 3만개정도 되는 데이터를 몇일간 확인하며 수정이 필요한 데이터를 추려, 일괄적으로 변경 및 부족한 보증금을 반환했다. 지금 생각하면 재밋는 추억거리지만, 당시에는 정말 끔찍했다.😂
테스트 코드의 장점
그런일이 있고 바로 테스트코드 작성을 해야겠다고 너무 너무 절실히 느꼈다. 입사당시에 테스트 코드는 없었고, 이후에도 신기능 개발과 수정 그리고 전체적인 validation과 인증 수정을 거치느라 테스트코드 작성에 대한 생각은 머리속에만 있었는데 당장 필요하다고 느꼈다.
그래서 데이터 수정 이후, 바로 테스트 코드 작성에 들어갔고 생각보다 쉽지 않았다. jest를 통해 테스트코드를 작성해본 경험이 있긴하지만 정말 겉핥기식으로 작성해본 것이라, 만만치 않았다. 그리고 전체적인 코드에 대한 테스트를 작성하려면 시간이 너무 소요되기 때문에, 가장 중요한 주문, 보증금 반환, 픽업, 반납에 대한 부분들을 작성해 나갔다.
아래의 순서로 진행해나갔다.
jest환경설정- 테스트를 위한
fixture추가- 전체적인 테스트 케이스 나누기
- 테스트 코드 작성
테스트 케이스를 작성하다보니, 왜 기능들을 작게 쪼개야하는지 느낄수 있었다. 여러 기능들을 하나로 묶어서 만들어논 코드들은 테스트하는게 쉬운게 아니었다. 코드가 긴만큼 테스트 코드도 길어졌다. 이러한 점은 e2e 테스트를 작성할 때에도 마찬가지였다.
결과적으로, 테스트 코드를 작성하면서 좀 더 기능들을 쪼개고 수정하는 계기가 되었고, 확실히 테스트 코드를 작성하고 나니 마음에 걱정도 덜어지고 생각하지 못했던 오류들을 찾아낼 수도 있었다.
뿐만 아니라, 후에 주문 환불 기능을 개발할 때, 먼저 어떤 테스트 케이스가 필요한가에 대해 작성한 후, 기능을 제작해본 적이 있었는데, 무지성으로 코딩하던 나에게 낯설고 어려웠지만 필요한 기능, 에러처리 들에 대해 한번 생각한 후 진행하게 되어 안정감이 느껴졌다.
테스트 코드의 장점
- 테스트코드를 쉽게 작성하기 위해 어떻게 코드를 나눠야할지 생각해보게 된다.
- 코드를 작성하기 전, 미리 테스트케이스에 대해 정리해보면서 어떤식으로 코드를 짜야할지 정리 할 수 있다.
- 테스트케이스를 보면 어떤 기능을 수행하는지 짐작할 수 있다.(spec의 역할)
- 내가 짠 코드에 대한 어느정도의 믿음이 생긴다.
통합테스트의 문제점
당시에 작성할 때는 모든 테스트를 통합테스트로 작성했었다. 데이터베이스 없이는 테스트를 돌릴 수 없고, 통합테스트이다 보니 시간도 오래걸렸다. 그러다보니 작은 기능을 수정하더라도 테스트를 하는데 걸리는 시간이 오래걸렸다. 그렇게 단위테스트의 필요성을 느끼게 되었다.
