테스트 방향 선회

무엇을 보다는 어떻게 할 것인지 고민하기

테스트 코드를 실제 프로젝트에 적용하게 된 지 두 달 정도가 지났습니다. 테스트 코드를 도입하기 위해 처음 고민했던 구조는 테스트 피라미드에 따라 폴더를 생성하고 그 폴더에 테스트 대상의 테스트 코드를 작성하는 구조로 진행했습니다. (자세한 테스트 코드 도입기는 이 글에서 확인하실 수 있습니다)

처음 테스트 코드를 적용하는 것이기에 특별한 전략을 세우고 이에 기반하여 테스트를 작성해 나가기보다 그동안 쌓아두고 학습해 뒀던 지식을 기반으로 테스트 코드를 작성해 나가면서 프로젝트에 어떤 식으로 반영해야 될지 직접 문제에 부딪혀 보며 감을 익히자는 느낌으로 진행되었네요.

하지만 테스트 피라미드에 따른 테스트를 작성하다 보니 문제가 생겼습니다. "테스트 커버리지를 높게 잡자"라는 것이었습니다. 테스트 코드를 도입하는 나가는 과정이다 보니 무조건 높은 테스트 커버리지를 유지하기 위해 테스트 비용이 가장 비싸다는 End-to-End 위주로만 테스트 코드를 작성하게 되는 편향에 빠졌습니다.

"테스트 커버리지"란 쉽게 말하면 수행한 테스트가 테스트 대상을 어느 정도 커버했는지를 나타내는 것입니다. 즉, 높으면 높을수록 좋습니다. 실제로 End-To-End 테스트를 도입해 나가면서 커버지리를 측정했을 때  76% 정도가 나왔습니다. 처음 도입한 것을 감안하자면 꽤 높은 지수라고 생각되었고 테스트 코드가 잘 적용되어 나간다는 착각에 빠졌습니다.

높은 테스트 커버리지를 달성하기 위해 End-To-End 테스트만을 작성하다가 문득 "이대로 괜찮은가?"를 다시 한번 짚어볼 수밖에 없었습니다. 고민되었던 관점은 다음과 같습니다.

자주 실행되는 테스트를 작성하고 있는가?

테스트를 자주 실행하는데 문제없는 테스트를 작성하고 있는가?

첫 번째로 "자주 실행되는 테스트를 작성하고 있는가?"는 End-To-End Test를 진행하기 위해 BackEnd API를 호출하는 것을 기준으로 테스트를 작성하는 것은 애초에 시간이 소요됩니다. 그렇다 보니 수정사항이 작더라도 처음부터 API를 호출하여 테스트하는 것이기 때문에 자주 실행하는데 문제가 됩니다.

두 번째로 "테스트를 자주 실행하는데 문제없는 테스트를 작성하고 있는가?"는 API를 호출하기 위해 가정되어야 하는 "Dependency"에 관련된 환경을 신경 써야 하기 때문에 자주 실행하는데 항상 문제가 없을 거라고 보장되지 않았습니다.

이러한 고민들이 테스트 코드를 처음 도입하는 과정에서 End-To-End 테스트를 위주로 작성하는 것이 맞는지 스스로 납득이 되지 않았습니다. 처음부터 뭔가 대단한 목표를 잡고 시작하는 게 아닌가 싶어 테스트의 가장 기본으로 돌아가기 위해 "단위 테스트"를 중심으로 하나씩 만들어가기로 결정했습니다. 

그러하여 테스트 피라미드에 따른 정의를 사용하지 않고 테스트 대상과 테스트 코드를 1:1 매칭시켜 테스트를 진행하기로 방향을 선회했습니다. 이전보다 테스트 커버리지율은 떨어졌으나 고민했던 관점인 "자주 실행되는 테스트", "자주 실행하는데 문제없는 테스트"를 달성하고 있습니다.

테스트 방식을 변경한 지 얼마 안 되었기 때문에 유의미한 결과로 이어지는지 두고 봐야 알 것 같습니다만  이번 사례를 통해 알게 된 건 무조건 높은 커버리지율 보다는 테스트 전략을 어떤 식으로 가져갈 것인지에 대한 고민을 중점으로 테스트 코드를 작성해 나가는지가 실제 개발에 도움이 된다는 점입니다.

저는 아직 변경이 가능할 때 선회했기 때문에 테스트 방식을 바꿀 수 있었서 다행이었습니다. 실제로는 그러지 못한 상황이 많을 것인데 이러한 상황에서는 또 어떻게 문제를 풀어나가야 할지를 한 번 고민해 보는 것도 염두에 둬야겠습니다.