안녕하세요.
오늘은 테스트 코드에 대해 소개해드리려고 합니다.
저는 개발자가 되기 전부터 테스트 코드에 관심이 많았는데요. 테스트 코드를 작성하면 프로그램의 버그가 줄고 좀 더 안전한 코드가 되지 않을까 하는 바람이 있었습니다. 테스트 코드에 대해 공부하면서 테스트 코드가 만능이 아니란 건 알게 됐지만 테스트 코드의 중요성에 대해서는 더 느낄 수 있었습니다.
오늘 글을 통해 테스트 코드의 중요성에 대해서 알려드리는 기회가 됐으면 좋겠습니다.
테스트 경험
대부분의 개발자분들이 테스트를 해봤을 겁니다. 안 해보셨다구요? 만약 프로그램을 완성한 후 작성한 코드가 정상동작 하는지 확인해 보셨다면 여러분은 테스트를 해보신 겁니다. 이렇게 사용자가 수동으로 프로그램이 올바르게 동작하는지 확인하는 것을 수동 테스트라고 합니다.
수동 테스트를 통해 프로그램이 올바르게 작성됐는 지 확인하고 서비스에 내보낼 수 있게 됩니다. 하지만 이런 수동 테스트는 한계가 있습니다. 인간이 테스트를 실행하고 결과를 일일이 눈으로 확인해야 한다는 점입니다. 그래서 일부 테스트 영역을 버튼 하나로 실행할 수 있는 자동화된 테스트를 사용하게 되는 데 이것을 자동 테스트라고 부릅니다.
저도 처음 프로그래밍을 배울때는 수동 테스트로만 프로그램을 테스트했는데 자동 테스트의 중요성을 깨닫고 나서는 자동 테스트를 작성하려고 노력했습니다. 이렇게 개발자가 작성한 코드를 버튼 하나로 자동 테스트하는 코드를 테스트 코드라고 부릅니다.
테스트 코드를 작성해야 하는 이유
테스트 코드를 작성해야 하는 이유는 여러 가지 있지만 제가 가장 중요하게 생각하는 이유는 하나입니다. 바로 테스트 코드는 프로젝트의 지속 가능한 성장에 도움을 준다는 점입니다. 저는 한 번에 완벽한 프로그램을 만들 수는 없다고 생각합니다. 지속적으로 발생하는 요구사항의 추가와 기존 설계를 리팩터링 하기 위해서는 테스트 코드가 필요합니다.
새로운 기능 추가 시에 새로 작성한 코드 혹은 수정한 코드가 기존에 잘 동작하는 부분에 영향을 주는 지 파악하는 일은 매우 어렵습니다. 이런 의도치 않은 결과가 발생하는 것을 사이드 이펙트가 발생했다고 하는데 테스트 코드를 이용하면 사이드 이펙트가 발생했는 지 비교적 쉽게 파악할 수 있습니다. 테스트를 돌려서 기존 기능이 제대로 동작하는지 확인하면 됩니다. (간단하죠?)
물론 테스트 코드를 작성하지 않았던 부분에서 발생하는 사이드 이펙트는 확인할 수 없지만 이미 테스트 코드를 작성한 부분에서 발생하는 것은 문제 파악이 가능합니다.
만약 우리가 만드는 프로그램의 수명이 짧다면 테스트 코드를 작성할 필요는 없습니다. 당장 내일 제출해야 하는 과제나 알고리즘 문제 풀이, 간단한 스크립트는 테스트 코드를 작성하는 비용이 더 큽니다. 며칠 지나면 사용하지 않는 코드에 테스트 코드를 작성하는 시간이 낭비가 될 수 있습니다. 나중엔 안 쓸 코드니까요.
하지만 실무에서 작성하는 코드는 다릅니다. 현재 사용자들에게 서비스하는 코드는 앞서 예시로 든 코드보다 훨어어어씬 수명이 깁니다. 이런 코드에 작성하는 테스트 코드는 작성하는 비용 대비 얻는 효과가 더 클 수 있습니다. 때문에 지속가능한 프로젝트를 위해서는 테스트 코드 작성은 필수라고 생각합니다.
테스트 코드 작성의 장단점
제가 생각한 테스트 코드의 장점은 다음과 같습니다.
- 빠른 버그 감지 및 빠른 수정
- 코드의 문서화
- 안정성 확보
- 리팩토링 지원
- 개발자의 자신감 향상
우리가 만드는 프로그램에 버그가 생기는 걸 원천차단하는 건 불가능합니다. 그러나 테스트 코드를 작성하면 작성하지 않았을 때보다 비교적 더 빠르게 버그를 발견할 수 있습니다. 그리고 개발자가 발견한 버그는 비교적 쉽게 수정할 수 있습니다. 프로그램 개발 단계에서 개발자가 발견한 버그를 수정하는 것과 배포 직전의 QA에서 수정하는 것은 정말 큰 차이가 존재합니다. 배포에 가까운 단계에서 버그를 발견할수록 버그를 수정하는 데 드는 비용이 올라갑니다(각종 커뮤니케이션 비용과 문제를 해결하는 데까지 걸리는 시간이 늘어납니다). 이렇게 버그 수정 단계를 앞으로 당기는 것을 원점 회귀(shift left)라고 하는데 테스트 코드는 원점 회귀하는 데 도움을 줍니다.
그리고 테스트 코드의 또 다른 장점 중에 하나는 코드의 문서화입니다. 테스트 코드를 작성하게 되면 코드에 대한 명세와 입력, 출력 결과를 작성하게 되는데 이런 것들이 해당 코드의 문서자료라고 볼 수 있습니다. 저는 기존 프로젝트를 분석할 일이 있으면 테스트 코드부터 확인합니다. 테스트 코드가 잘 작성됐다면 해당 프로젝트에 대한 정보를 좀 쉽게 확인할 수 있기 때문입니다.(잘 작성돼 있다면 말이죠...)
반대로 굳이 테스트 코드의 단점을 뽑아보자면 다음과 같은 점들이 있을 수 있습니다.
- 테스트 코드를 작성하는 데 드는 비용
- 테스트 코드를 잘 작성하기 어려움
- 초기 단계에서는 명세가 변경해 테스트가 어려움
테스트 코드를 작성하는 데 드는 비용이 단점일 수는 있지만 앞서 말씀드렸다시피 수명이 긴 프로젝트에서는 테스트 코드 작성 비용보다 얻는 이득이 크기 때문에 테스트 코드를 작성하는 게 더 좋다고 생각됩니다. 수명이 짧은 프로그램이라면 테스트 코드를 작성하지 않아도 됩니다.
그리고 테스트 코드를 잘 작성하기 어렵다는 단점이 있는데 이 부분은 실제로 그런 경우가 좀 있습니다. 기존에 있는 프로젝트에 테스트 코드를 추가해야 하는데 어려웠던 경험이 있고요. 이 부분은 기존에 작성된 코드가 테스트하기 어렵게 짜인 코드일 확률이 높습니다. 좋은 테스트를 위해서는 적당한 크기로 나눠지고 의존성도 적당히 분리된 코드가 좋은데 그렇지 않은 경우 기존 코드를 수정해야 합니다. 결국 이 단점은 테스트 코드 자체의 문제라기보다는 코드의 문제일 수 있습니다.
마지막으로 명세가 빠르게 변하는 프로젝트 초기 단계에서 테스트 작성하기가 어렵다는 단점이 있는데, 이 부분도 마찬가지로 테스트 코드 자체의 문제라기 보다는 명세가 계속 바뀌는 점이 문제라는 생각이 드네요.
결론
테스트 코드에 대해서 테스트 경험과 장단점, 테스트 코드를 작성해야 하는 이유에 대해서 알아봤습니다. 결국 핵심은 계속 강조드린 대로 작성하는 프로그램의 수명에 따라서 테스트 코드를 작성할지 정해야 한다는 겁니다. 그러나 프로그램의 수명을 알 수 없는 경우도 있습니다. 이런 경우 프로그램의 수명이 길어지길 바라면서 테스트 코드를 작성하는 것은 어떨까요?
다음에 작성할 글은 intellij에서 junit5를 이용한 테스트 코드 작성법에 대해 알아보겠습니다.
긴 글 읽어주셔서 감사합니다.
댓글