테스트 코드, 왜 작성하는가

나는 왜 테스트 코드에 관심을 가졌는가

때때로 사이드 이펙트에 대한 두려움으로 인해 리팩토링을 포기하고 방치하게 되는 코드들이 존재했다. 서비스가 커질수록 코드 간의 의존성이 커지고 작은 부분의 수정으로도 영향을 받는 곳이 너무 많아 코드 수정이 부담스러워진다. 테스트 코드가 이러한 부담을 줄여줄 것으로 기대했다.

 

실무 프로젝트 1차 도전

신규 프로젝트인 만큼 서비스의 방향성이 자주 바뀌고는 했다.
큰맘 먹고 테스트 도입을 시도해 보았으나 기획이 바뀌어 개발해두었던 코드를 오히려 전부 걷어내거나 디비 구조가 대대적으로 변경되는 일들이 발생했다.
기능 개발에 여유가 있는 시점에 조금씩 도입을 해보았는데, 큰 변경 사항들이 생기자 테스트 코드를 관리할 여유가 없었고 본 코드가 사라진 테스트 코드들은 주인을 잃은 코드가 되었다.

결국… 팀의 첫 테스트 코드 도입은 길을 잃었다. 

 

그럼에도 불구하고,

나는 테스트 코드가 안정적으로 도입되었을 때 아래와 같은 이점이 있을 것이라 기대한다.

리팩토링에 대한 자신감을 가질 수 있다.
앞서 얘기한 것처럼 이미 반영된 코드를 수정한다는 것은 언제나 부담스러운 일이었다. 수정으로 인한 사이드 이펙트에 대한 두려움으로 인해 bad smell이 나는 코드도 당장 손대지 않게 되고 이런 코드들은 결국 방치된다.
테스트 코드는 안전장치라고 생각한다. 테스트 코드를 견고하게 작성한다면 사이드 이펙트 이전에 버그를 많이 방지할 수 있을 것으로 기대한다.

변경에 유연하게 대처할 수 있다.
신규 기능 혹은 기존 기능의 개편이 있을 때 기획&개발 모두가 사이드 이펙트에 대한 두려움을 가지게 되는 상황들이 꽤나 있다. 어떤 상황에서도 요구 사항을 안정적으로 반영할 수 있고 유연하게 대응할 수 있는 것이 개발자의 역량이라고 생각한다. 테스트 코드가 이를 도와줄 것이다. 

테스트 코드 작성은 더 좋은 코드 작성을 도와준다.
여기서 더 좋은 코드란 의존성은 낮고 응집성은 높은 코드 정도로 얘기할 수 있을 것 같다. 테스트 코드를 작성하는 과정에서는 자연스럽게 해당 사항들에 대해서 점검하게 된다는 것을 느꼈다.

내가 작성한 코드의 핵심 로직을 다른 개발자가 쉽게 이해할 수 있다. (다른 개발자가 작성한 코드를 내가 쉽게 이해할 수 있다.)
개발자는 코드를 작성하는데 5퍼센트의 시간을 쓰는 반면 작성된 코드를 분석하는 데에 95퍼센트의 시간을 사용한다는 얘기를 들어보았을 것이다. 테스트 코드는 일종의 문서화 같은 역할을 할 수 있다. 해당 영역의 핵심 기능을 그 자체로 서술 해주고 다른 개발자가 코드를 파악하는 데에 도움을 줄 수 있을 것이다.

위와 같은 이점을 기대하고 있으나 올바르게 관리되지 않는 테스트는 오히려 비용임을 인지하고 있다.
최대한 이득을 얻을 수 있는 방향으로, 앞으로는 기획적으로 변경되지 않을만한 코어한 비즈니스 로직들부터 점차 테스트 코드를 작성해나가려 한다.
다양한 상황에 대해 계속해서 적용해 보면서 노하우를 쌓아가자.