초짜 파이썬 개발자가 서비스 만든 썰 푼다 -04-

테스트 코드를 나중에 만드는 놈이 있다고? 그게 나여...

0. 원칙적으로, 테스트 코드는 필요한 코드를 작성할때 같이 작성하라고 한다. 나도 이에 대해서는 동의한다. 특히 테스트 코드를 만들어 뒀을때 제일 좋은것은 뭔가 갈아 엎어야겠다 싶을때 속 편히 갈아 엎을수 있다는 점이 가장 좋을 것이다. 대대적인 구조 변경이 있을때 그로 인한 사이드 이펙트에 대해서 아주 쉽게 검증할수 있다는 것은 정말로 큰 의지가 된다.

마틴 파울러 옹께서도 그렇다고 합니다.

1. 개발 초창기에 나도 테스트 코드와 함께 필요한 코드를 작성하려는, 이른바 TDD를 진행하려 했다. 하지만 당장 파이썬도 익숙치 않은데 거기에 FastAPI와 SqlAlchemy까지 어떻게 핸들링하면 좋을지 참 난감하더라.

원래 내가 생각하던 테스트는 각각의 레이어별로 분리된 테스트를 생각했었다. 그런 테스트를 만들고 싶었는데 FastAPI 문서를 찾아봐도 그런건 안보이더라. Pytest로 API 단위로 테스트 하는건 존재하는데 레이어 단위로도 쪼재서 테스트 하는거 아닌가 싶기도 하고..

결국 초창기 코드 분량이 작을때는 변경이 있을때마다 일일히 테스트를 돌려보자! 라는 생각에 Postman만 의지해서 작업을 시작했다.

2. 프로젝트 초창기에는 그정도로만 해도 충분했다. 하지만 코드 베이스가 점점 커지고, 특히나 경험이 쌓이면서 이전에 해놓은 것들에 대해 이게 아니야 싶은데(대체 뭐가 아니야 싶었는지 궁금하신 분은 이글 포함 시리즈를 쭉 읽어주세요) 손을 대려니 역시 막막하더라.

이 핑계도 한계가 있습니다.

그래서 결국 날을 잡아 테스트 코드를 만들어버렸다. Pytest로.

3. 그런데, 의외로 그정도 테스트로도 충분하더라. 내가 생각한 레이어 단위로 나뉘어져 있는 테스트는 오버스펙이었던 것이다. 그러면서 예전에 이 생각때문에 같이 일하는 사람들과 충돌한적이 생각나는데 어찌나 스스로가 부끄럽던지.

다만, Pytest만으로 테스트를 굴리는데 뭔가 아쉬운게 많기에 tox로 테스트를 관리하고 있다. 저거 쓰면 테스트 환경과 실제 서비스 환경을 필요에 따라 구분할수 있어서 대단히 편하더라. 물론 두 환경을 관리해야 하는 부담정도는 있지만 편리한 테스트가 주는 혜택에 비하면 그정도 쯤이야.

4.그렇게, 테스트 커버리지 0%의 코드는 이글 작성하고 있는 현재 기준 86%달성하고 있다. 뭐랄까 나름 잘했다 칭찬해주고 싶은데 그런 희망찬 이야기만 하고 있다면 이 시리즈 시작할 생각도 안했것지.....