올해 회사 주요 목표 중 하나로 안정성 강화가 선정됐다.
안정성 강화 주요 목표로 테스트 코드 작성이 나왔는데 해당 목표 달성을 위해 고민하고 적용한 내용을 풀어보려고 한다.
물론 아직 현재 진행형이기 때문에 좋은 내용이 있으면 공유 부탁드립니다.
기본적으로 테스트 코드를 예전에도 작성해 보면서 흉내를 내보았다고 생각한다.
이전 시도에선 그냥 테스트 코드가 좋다고 하고 직접 해보지 않아도 공감되는 장점이 많아서 시도했다.
그때 해보면서 느낀 점은
1. 테스트 코드가 좋지만 이게 진짜 제대로 검증이 된 건지 의문
2. 어설프게 설계되어 간단한 로직 변경인데 테스트도 전부 수정해야 되는 부분
3. 2번의 연장선으로 테스트도 왕창 변경하게 되어 신뢰성과 지속성을 잃게 된 부분
이렇게 체감한 문제들이 있어서 우선 테스트 코드 작성을 중단하고 앞선 문제들을 어떻게 해결하고 있는지 검색을 많이 해보았다.
그래서 검색과 고민을 해보고 혼자서 끄적거리며 지금 현재 장고로 테스트 코드 작성을 해보며 느낀 진화된? 문제들이 다시 생겼다.
우선 기존에 장고로 테스트 코드를 작성해 보면서 개인적으로 느낀 부분은 자료 부족이다.
사실 지금까지 본 테스트 코드 작성, TDD 자료들은 모두 겉핥기 느낌이 강했다.
물론 내가 검색을 잘 못한 것도 있겠지만 그럼에도 불구하고 자료를 찾는데 굉장히 많은 시간이 들었다.
또한 다른 언어 자료를 어떻게 찾더라도 실제 장고로 코드를 작성하는 부분에서 대입하는 것도 힘든 부분 중 하나였다.
역시나 영어로 검색해야 그나마 생각의 실마리를 찾을 수 있는 자료를 구할 수 있었다.
두 번째는 생각보다 DB/모델과 의존성이 너무 높은 부분이다.
이건 식견 짧은 개발자의 생각일 확률이 높을 수 있다고 본다.
다만 실제 테스트 코드를 짜려고 했을 때 가장 처음 맞닥뜨린 부분 중 DB 즉, 모델 없이 주요 로직을 작성하고 코드를 짜는 게 굉장히 힘들었다.
회사에서 장고와 DRF를 사용해서 개발을 하는데 DRF의 보일러 플레이트를 사용하는 경우 생각보다 많은 부분에서 ORM이 사용되어 잘 피해야 했다.
내 생각에 장고는 기본적으로 뚱뚱한 모델과 얇은 뷰를 지향한다고 생각한다.
물론 이건 어떻게 쓰는지에 따라 다르겠지만 기본적인 방향성은 그렇다고 생각한다.
이런 부분은 장고 로직을 보면서 많이 체감을 했던 부분인데
이런 부분 때문에 테스트 코드를 작성할 때 테스트 코드의 효율을 높이기 위해
기존에 로직을 짤 때보단 편리하게 도움받은 부분을 많이 제한하게 되었다.
마지막으로 장고의 MVP에서 P 역할을 하는 뷰를 테스트하기가 굉장히 까다로운 부분이다.
이 부분 또한 경험이 적은 개발자가 말하는 것임을 감안해야 한다.
사실 앞의 두 부분은 DB와 모델의 역할을 최소화하고 ORM을 적용해야 하는 부분은 가장 마지막에 로직을 짜고 하는 방식으로 우회하는 방향이
존재했다.
다만 이 부분은 아직까진 깔끔하게 해결하는 방법을 찾지 못했다.
개인적으로 문제인 부분은 DRF를 사용하면서 viewset의 편리함이 좋았지만 단점은 다른 파일과 의존이 너무 강하게 걸려있는 것이라고 생각한다.
사실 의존이 강하게 걸려있는 건 잘 피하고 최소화하면서 줄일 순 있다고 생각하는데
잘 피하고 줄인다고 하더라도 없앨 순 없다고 생각하기에 문제라고 느껴졌다.
또한 내가 원하는 건 view만 호출해서 테스트를 하고 싶은데 많은 예제를 보았을 땐 view만 호출하는 게 아니라
view에 걸린 api를 호출해서 테스트를 하는 게 주요 방안으로 나와있어 아직까진 만족스러운 방안을 찾지 못하였다.
다음 글은 테스트 코드 작성을 위해 도입할 도구들과 이유를 설명해 보겠다.
