안드로이드 신입 개발자의 시선에서 본 테스트 코드

여러 개발자들에게 테스트 코드에 대해 물어보면, 의외로 비슷한 대답이 돌아온다.
“우리 회사에는 테스트 코드가 없다”는 말이다.

이유는 제각각이다.
필요성을 느끼지 못해서라는 사람도 있고, 바쁘다 보니 작성할 여유가 없었다는 사람도 있다.
솔직히 말하자면, 나 역시 한동안은 후자에 가까웠다.

입사 초기에 팀에는 안드로이드 개발자 한 분만이 중요하다고 판단되는 로직에 한해서 테스트 코드를 작성해두고 있었다. 다만 내가 담당했던 Feature 영역에서는 Repository, UseCase, ViewModel 등 중 어느 것도 “반드시 테스트가 필요하다”고 느껴지지 않았다. 그 당시의 나는 그렇게 판단했다.

생각이 바뀌게 된 계기는, 기존에 작성된 코드를 기반으로 새로운 기능을 구현하게 되었을 때였다.
Feature 하나를 완성하기 위해서는 과거 로직의 의도와 흐름을 먼저 이해해야 했다. 문제는 그 과정이 생각보다 훨씬 오래 걸렸다는 점이다. 관련된 Context를 하나씩 따라가다 보니, 객체와 함수 내부에는 복잡한 계산 로직이 얽혀 있었고, 이를 설명해주는 문서나 주석도 충분하지 않았다. 결국 디버깅을 반복하며 직접 흐름을 추적하는 것이 가장 빠른 방법이 되어버렸다.

그때 처음으로 이런 생각이 들었다.
“테스트 코드가 있었다면, 이 객체가 어떤 입력을 받아 어떤 결과를 기대하는지 훨씬 빨리 알 수 있었을 텐데.”
성공 케이스와 실패 케이스, 그리고 예외 상황이 테스트로 정리돼 있었다면, 코드를 ‘이해하기 위해’ 쓰는 시간은 지금보다 훨씬 줄었을 것이다.

코드를 이해한 뒤 기능 구현을 마치고 QA 단계에 들어갔다.
요구사항을 충실히 반영해 개발을 마쳤다고 생각했지만, QA 과정에서 내가 미처 고려하지 못했던 예외 케이스들이 하나둘씩 드러나기 시작했다. 요구사항의 경계에 놓인 애매한 상황도 있었고, 일부 동작은 애초에 명확하게 정의되지 않은 상태였다는 사실도 그때서야 알게 되었다.

해당 Feature를 잘 알고 있을 것이라 생각했던 개발자나 유관자들에게 물어봤지만, 명확한 답을 얻기는 어려웠다. 문서로 남아 있지 않은 영역이다 보니, 각자의 기억과 해석이 조금씩 달랐다. 결국 CTO님께 직접 이전 요구사항을 여쭤보며 맥락을 다시 정리했고, 그 과정을 문서로 남기기 시작했다.

요구사항이 정리되고 나니, 다음에 해야 할 일도 자연스럽게 보였다.

“이건 테스트로 남겨야겠다.”

그렇게 나는 기능 구현이 끝난 뒤 테스트 코드를 작성했다.
단순히 정상 동작만 검증하는 테스트가 아니라, QA 과정에서 드러났던 예외 상황과 애매한 경계 조건들을 하나씩 코드로 고정했다. 이 테스트들은 단지 품질을 보장하기 위한 도구가 아니라, 이 Feature가 어떤 전제를 가지고 설계되었는지를 가장 정확하게 설명해주는 문서가 되었다.

이 경험 이후로, 테스트 코드는 더 이상 “여유가 있을 때 작성하는 것”이 아니게 되었다.
테스트는 미래의 나를 위한 기록이자, 언젠가 이 코드를 마주할 누군가를 위한 최소한의 배려라는 생각이 들었기 때문이다.

앞으로는 비즈니스 로직처럼 여러 입력과 조건을 통해 결과가 도출되는 코드에 대해서는 테스트 작성을 기본으로 가져가려 한다. 또한 Hotfix로 배포되는 수정 사항은, 우리가 개발이나 QA 과정에서 놓쳤던 부분이라는 의미이기도 하기에, 반드시 테스트 코드로 남길 계획이다.

이 기준을 실제로 실천해보고, 분명한 효과가 나타난다면 개인의 습관에 그치지 않고 팀의 규칙으로 이어질 수 있도록 적극적으로 공유해볼 생각이다.

신입 개발자로서 테스트 코드를 바라보는 나의 시선은, 그렇게 조금씩 바뀌고 있다.