나는 Unit Tests(단위 테스트)를 별로 선호하는 편이 아니다.

이전 회사에서 한동안 단위 테스트를 해보았는데, 테스트 케이스를 작성하고 테스트 코드를 작성하는데,

체감상 그 기능을 개발하는 시간만큼의 시간이 들어가는 느낌이었기 때문이다.

그래서 '솔직히 게임 클라이언트 개발에 단위 테스트는 별로 안 맞지 않나?'라는 생각을 하고 있는데,

 

그러다가, 한번 이번에 다른 사람은 어떤 생각을 가지고 있을까 하고 찾아봤다.

그런데, 레딧에서 꽤 괜찮은 코멘트를 하나 발견했다.

...

The single biggest benefit I have personally experienced with writing tests is the impact it has on your code design, not the execution of the test itself. To make code testable you end up doing many things like having small, single-responsibility classes, separating
presentation and logic, injecting dependencies, minimizing number of publicly exposed methods, etc. etc. I would argue that these are almost always good thing. This is why writing tests early (even if not exactly TDD) is more valuable than retrofitting them afterwards.

...

https://www.reddit.com/r/gamedev/comments/4ghpwe/unit_testing_in_game_development/d2hpozk/

 

대충 설명하자면, 코멘트 작성자가 느낀 개인적인 단위 테스트의 가장 큰 장점은, 그 테스트 자체에 있다기 보단, 그 테스트를 하기 위한 과정들이 가장 큰 장점이라는 것이다. 그 과정들 자체가 코드의 품질을 좋게 유지시킨다고 얘기하고 있다.

 

보통 단위 테스트를 하기 위해선, 클래스 자체의 코드 품질이 꽤 좋아야 한다.

일반적인 조건들로는 다음과 같은 게 필요한데,

  • 실제 데이터를 사용하지 않고
  • 단일 책임 원칙을 지키고
  • 로직과 출력 코드를 분리시키고
  • 클래스 간의 의존성을 줄이고
  • 메소드 노출을 최소화
  • ... 등등

이와 같이 단위 테스트를 하기 위해선 클래스에 많은 노력이 들어가야 한다.

이런 조건들이 맞아야지만 단위 테스트를 할 수 있기 때문에, 단위 테스트를 준비하는 것 자체가 코드 품질을 좋게 유지시킨다는 것이다.

 

또한 코멘트 작성자는 단위 테스트는 필요는 하지만 너무 쓸데없이 모든 것을 테스트하려고 하거나 아예 안 하거나 하기보단, 딱 적절한 테스트 수준을 유지하는 게 나은 것 같다고 주장했다.

 

이 코멘트를 읽고 꽤 맞는 이야기라고 생각했다.

생각해보면 예전에 단위 테스트 코드를 만들 때, 테스트를 에러 없이 통과하기 위해서 이것저것 코드를 수정하면서 노력을 많이 해야 했고,

덕분에 관련 코딩 습관을 어느 정도 베개 할 수 있었기 때문이다. (아직 완벽하진 않지만)

어찌 보면, 꽤 좋은 선생님 역할을 해준 셈이다.

 

이 코멘트를 읽으며, 어느 정도 단위 테스트가 필요할 수 있겠구나를 생각할 수 있게 되었다.

 

만약 지금 프로젝트를 진행 중인데, 높은 코드 품질을 장기적으로 유지하고, 다른 개발자분들이 유지보수에 좋은 코딩에 익숙하지 않다면,

단위 테스트를 적용해보는 것도 팀의 실력 향상과 프로젝트의 품질에 꽤 좋은 도움을 줄 거 같다고 생각한다.

+ Recent posts