테스트 코드 뭐하러 작성해?🤔
Categories: Projects
테스트 코드 도대체 왜 작성하는걸까🤔
몇달전에 꼼꼼함에 대한 개인적인 짧은 회고를 한번 작성했는데, 거기서 잠깐 나왔던 테스트 코드에 대해서 고민했던 소소한 생각들을 적어 놓으려고 한다
테스트 코드 도대체 왜 작성하는걸까
이 질문은 솔직히 테스트 코드라는걸 처음 공부하고 배우기 시작했을때부터 생각을 많이 했던것 같다. 프로젝트의 빡빡한 일정 맞추느라 바빠 죽겠는데… 테스트 코드는 언제 작성해 🫠 라는 생각을 하면서 결국 마음의 짐으로만 남긴채 테스트 코드를 작성 안하거나, 프로젝트 막바지에 어거지로 테스트 코드를 보충했던 적이 솔직히 굉장히 많았다.. (반성중인 부분..)
하지만, 프로젝트 몇개 하면서 느낀점이 두가지 있었다. 그 두가지 때문에, 나는 이제 테스트 코드 없이는 개발을 안하는 개발자가 되기로 결심했다.
첫 번째, 테스트 코드를 개발과 병행하면 어쩔 수 없이 꼼꼼해진다.
테스트 코드는 개발과 병행(꼭 TDD까지는 아니더라도) 해야만 가장 순수하고 효과적인 형태의 테스트 코드가 될 수 있다. 개발 다 하고 마지막에 테스트 코드를 작성하면, 그 테스트 코드들은 작성하면서 분명히 어느정도 compromise 가 생길 수 있고, 그러면서 corrupt 된 테스트 코드가 될 확률이 높다. 그럼 아주 자연스럽게, 그냥 통과를 시키기 위한 잘못된 테스트 코드가 될 수도 있고, 결국 그냥 아무런 효과가 없는 테스트 케이스가 될 확률도 있는 것이다.
그럼 반대로 개발과 병행하면서 짜는 테스트코드는 뭐가 좋을까?
테스트 코드에 대해 다음과 같은 두 가지 고민만 제대로 해도 얻게 되는 것이 너무 많아진다.
- 어떤 케이스들에 대해서 작성하지?🤔
- 어떻게 SUT(System under Test) 를 테스트 하지?🤔
1. 어떤 케이스들에 대해서 작성하지?🤔
어떤 케이스들에 대한 테스트 코드를 작성할지 고민해보면, 자연스럽게 프로젝트 요구사항의 A~Z 를 다 확인하면서 고민하게 된다. 이러면 뭐가 좋을까? 첫째로, 요구사항을 제대로 이해한 상태로 코드 작성을 시작할 수 있고,(잘못 이해한 경우로 프로젝트 시작하는 경우 생각보다 많음. 특히 복잡한 프로젝트일 수록) 테스트 케이스를 작성하려고 하다보면, 디테일한 부분까지 고민을 하게 되기 때문에, 이해 안되는 요구사항을 미리 캐치해서 미리 질문도 할 수 있다.
두번째로, 다양한 엣지 케이스들을 처음부터 고려한 좋은 코드가 자연스럽게 탄생된다. 즉, 개발 하고 있는 코드 의 주요 로직 곳곳에 엣지 케이스를 처리하는 가드문과 땜빵식의 if 문이 남발되는 현상을 어느정도 피할 수 있다.
세번째로, 다양한 케이스들에 대해서 미리 고민을 했기 때문에, QA 기간에 나타나는 버그가 확 줄어든다 👍
2. 어떻게 SUT(System under Test) 를 테스트 하지?🤔
어떻게 SUT 를 테스트 시키지 ? 라는 고민을 하면서 테스트 코드를 먼저 작성하면, 우리가 항상 추구하는 Testable한 Software 이 자연스럽게 탄생된다. 우리가 좋아하는 클린 아키텍쳐, Object-Oriented 코드, 죄다 테스트성을 높이기 위해 하는거 아닌가? 백날 고민하고나서 코드 짜고 테스트 작성해봤자, 아차 하고 이거 잘못 설계 했네? 라는 생각이 들 수 있다. (사실 나만 그럴지도) 그런데 테스트를 먼저 작성하고 개발과 설계를 하게되면, 관심사 분리, SRP, 의존성 역전, 이런건 어쩔 수 없이 따라오게 된다.
두 번째, 리팩토링을 자신있게, 신나게, 행복하게 할 수 있다
우리는 항상 레거시 코드와 씨름하면서 개발한다. 프로젝트 개발하고 1주일만 지나도 내가 개발했던 코드(당시에 마음에 들었어도)는 낯설어지고 마음에 안드는 부분들이 보이기 시작하고 그런다. 코드를 좋아하고 장인 정신을 갖고있는 개발자일 수록 그런 현상은 자연스럽다고 생각한다. 그래서 우리는 항상 코드를 조금씩 수정해가면서 유지 보수를 해야되는데, 테스트 코드가 없으면 버그가 생길까봐, 예상하지 못했던 사이드 이펙트가 생길까봐, 장애가 생길까봐, 주말에 멘션 걸릴까봐 걱정하면서 결국 안하게되거나, 소심하게 리팩토링을 하게된다. 그러면 자연스럽게 코드들이 조금씩 손길을 안받기 시작하고, 엄청나게 냄새나는 레거시 코드로 남게 되는 것이다.ㅜㅜ
테스트 코드가 꽈꽉 채워진 모듈은 어떨까? 조금이라도 더 마음을 놓고 리팩토링을 할 수 있게 해주는 것이다.
내가 요기요에 들어가서 처음으로 했던 프로젝트에서, 하나의 화면을 (테스트 코드도 전혀 없었던 화면임) 처음부터 끝까지 뜯어고쳐서 리팩토링을 했었다. (지금 생각하면 진짜 용감하다) 결국 나는 장애라는 쓴 약을 처음으로 맛보게 되었고, 코드 수정에 대해서 꽤 자신감이 떨어졌던 적이 있다.
테스트 코드를 열심히 짰으면 안그러지 않았을까… 아무튼, 그런 일이 있었기에 테스트 코드 좋아하는 내가 탄생했으니까 뭐 소중한 경험으로 생각하고 있다.
마무리
여전히 남아있는 고민..Test Coverage 를 어느정도 가져가야할까?
사실, 100% coverage 를 채우는건..당연히 너무 이상적이지만, 복잡한 프로젝트일 수록 꽤나 어려운 일이다. 모든 가능한 케이스를 생각 해내서 테스트 코드를 작성하는건 분명히 불가능에 가까울 것이다. 일단 가장 최근에 했던 프로젝트에서는 QE 에게 테스트 케이스 Spreadsheet 를 달라고 해서, 그걸 토대로 테스트 케이스를 작성했었다. 그래야 QA 기간에 버그를 최소화 시킬 수 있을것 같았고, PO, QE, 개발자끼리 정한 요구사항에 대한 케이스들이니까, 그게 가장 우선순위 되어야하는 케이스라고 생각했었다. 물론, 완벽하지는 않다.. 왜냐하면 아무도 생각하지 못했던 케이스도 있을 수 있으니까. 아직도 고민되는 부분이고, 어떤 기준으로 테스트 케이스의 우선순위를 정해서 작성하는지에 대한 작전은 앞으로도 계속 짜봐야될것 같다.