테스트 코드를 모르면 손해 보는 3가지
혹시 테스트 코드에 대해서 들어보셨나요? 테스트 코드를 간략하게 표현하자면 다음과 같습니다.
내 프로젝트 코드에 오류가 있는지 검증하기 위해 매크로 프로그램을 만든다.
이게 무슨 소리인가 싶으신 분들도 있고, 고개를 끄덕이시는 분도 있을 겁니다. 일단 제가 처음 경험했던 납득이 되지 않는 이야기 하나를 해 드릴게요. 아 그전에 앞서 제가 하는 테스트 코드는 백엔드 개발에 관련된 부분입니다.
물론 프런트엔드 역시 UI가 잘 동작하는지, 통신 이후에 로직이 잘 수행되는지 등등의 테스트 코드를 작성하는 방법들이 있습니다. 하지만 어느 한쪽으로 설명하는 것이 아무래도 이해가 쉽기 때문에 이번에는 백엔드 개발자의 기준으로 설명드리고자 합니다.
테스트 코드는 마법 같은 안전장치가 아닙니다. 이것을 위해서는 직접 개발을 할 때 들이는 노력만큼이나 시간과 에너지를 써야 합니다. 솔직한 심정으로 이게 뭐 하는 거지? 싶을 정도였는데요.
그래서 이걸 불필요하게 느끼는 것도 충분히 공감이 갑니다. 실제로 한번 만들어 놓고 잘 돌아가는 코드를 다시 볼 일이 (정말로) 없다면 테스트 코드는 필요 없을지도 모르겠습니다.
그렇지만 만들어 놓은 코드를 유지보수해야 할 일이 있다면 테스트 코드는 아래와 같은 부분에서 많은 도움을 주게 될 것입니다.
테스트 코드의 이점 3가지
1. 코드를 수정했더니 오류 발생
여러 가지 상황이 있을 수 있습니다. 우선은 A라는 문제가 하나 발생했다고 생각해 봅시다. 개발자들은 서둘러 A를 수정합니다. 그리고 빌드 후 실행을 해보니 별 문제가 없는 것 같습니다. 최종적으로 배포를 해 보니 예상하지도 못한 B에서 문제가 발생합니다.
혹은 B는 예상했어야 할 문제였는지도 모릅니다. 그런데 수많은 소스코드를 보면서 일일이 그것을 어떻게 다 체크할까요? 조금 더 개발자의 입장에서 깊게 들어간 설명을 해보겠습니다.
어떤 회원 정보가 있는데 이 회원정보에 전화번호 항목이 휴대전화 항목으로 변경되었다고 가정해 봅시다. 그러면 어디를 개발해야 할까요? 회원가입, 회원 조회, 개인정보 수정 정도가 생각나겠네요. 개발자는 이 부분을 수정합니다.
그리고 배포를 했을 때도 문제가 없었습니다. 그런데 며칠 후 고객센터에서 연락이 옵니다. 휴면 상태였던 회원이 정상적으로 휴면 복구가 처리가 되지 않는다네요.
깜빡하셨나요? 이럴 때 미리 테스트 코드를 만들어 두었다면 문제를 어느 정도 해결 할 수 있습니다.
2. 귀찮은 테스트를 대신해 줌
테스트 코드가 없었다면 1번과 같은 사항을 해결하기 위해서 어떻게 해야 했을까요? 엑셀 문서를 만들어서 가급적 모든 생각나는 상황에 대해 가정하고 여러 가지 테스트 시나리오를 작성하는 것입니다.
예를 들면 이렇게요
1) 회원가입 시 전화번호 항목을 빼고 가입을 누르면 동작하지 않아야 한다.
2) 로그인 시 비밀번호에 해킹 관련 특수문자를 넣으면 동작하지 않아야 한다.
3) 개인정보 수정을 하고 모든 항목이 잘 바뀌었는지 확인한다.
그리고 소스코드를 수정할 때마다 작성했던 시나리오대로 한 번씩 실행해 보면 됩니다. 벌써부터 지긋지긋해지죠? 실제로 이 테스트 코드의 항목은 위 예시처럼 3개가 아닙니다.
중요한 서비스 오픈 전이라면 여러 사람들에게 테스트를 시켜보고 이때 나올 수 있는 경우의 수는 100가지도 넘을뿐더러 그러한 테스트를 다 하고 나서도 문제가 발생합니다.
테스트 코드는 위 예시와 같은 행동을 대신해 주는 소스코드를 작성하는 것이라고 볼 수 있습니다. 그리고 자신의 코드가 배포되기 전 모든 테스트를 수행하는 명령어 한 번이면 이 테스트 코드들이 매크로 동작하듯이 하나씩 수행한 후 결과를 알려줍니다.
3. 추후에 다시 수정하려고 했더니 어느 부분을 고쳐야 할지 확신이 서지 않음
시간이 지나서 혹은 새로 입사한 회사에서 기존 소스코드를 수정해야 되는 임무를 받았다고 생각해 봅시다. 소스코드를 분석하는데만 해도 어마어마한 시간이 소요되는데 수정 후 결과물이 정상적으로 동작한다고 보증할 수 있을까요?
서비스되고 있는 프로그램은 수정하기가 굉장히 까다롭습니다. 왜냐하면 잘못된 로직으로 인해 데이터베이스에 들어갈 데이터가 변경되어 버리고 그러면 데이터가 오염되는 것이나 다름없습니다. 데이터베이스는 정제된 "정보"를 담음으로써 가치를 가지는데 이게 오염되면 다시 청소하기는 몇 배는 힘들 겁니다.
이때 도움 되는 것이 테스트 코드입니다. 과거의 어떤 사람 혹은 나 자신이 만들어둔 안전장치와도 같습니다. 물론 이것이 100% 안전을 보장해 주는 것은 아니지만 수없이 돌아가는 테스트 항목을 보면서 수정사항을 적용했을 때 어딘가 잘못된 점은 없는지 확인해 주기에 굉장한 안심이 되는 것도 사실입니다.
힘든 점도 있어요
물론 마냥 좋은 것은 아닙니다. 처음 말씀드렸듯이 테스트코드는 알아서 자동으로 잘해주는 마법과 같은 코드가 아닙니다. 그러한 테스트 코드는 직접 작성해야 합니다.
그리고 그냥 개발과는 또 다른 테스트용 로직과 개념을 몇 가지 더 익혀야 합니다. 또 개발하는 코드 라인 수보다 더 많은 양의 테스트코드를 작성하게 될 수도 있습니다.
제가 가장 힘들었던 점은 이러한 상황에서는 테스트코드를 어떻게 작성해야 하지?라는 의문이 끝도 없이 들었습니다. 그리고 이것에 도움이 되는 글은 그렇게 많지도 않았었고요. 그런데 테스트코드를 작성하다 보니 그럴만한 이유가 있었습니다.
개발 방법론도 수많은 방법론이 있듯이 테스트코드도 자신이 작성한 코드를 기반으로 생성되기 때문에 어마어마한 방법이 있을 수 있다는 걸 알게 되었습니다. 이상적인 테스트 코드를 작성하는 것이 아직도 제 목표이니 지금도 저는 제대로 된 테스트 코드를 작성하고 있다고 보고 있지 않는 셈입니다.
그럼에도 경험상 잃는 것(시간, 정신적 스트레스) 보다 얻는 게 더 많았습니다. 개발 속도가 정말 급하면 어쩔 수 없겠지만 저는 조금이라도 여유가 있다면 테스트코드를 작성하고 있습니다.
여러분도 한번 살펴보시는 건 어떨까요?
