테스트 코드를 왜 작성할까요?
최근 서비스 레이어에 테스트 코드를 작성하면서 느꼈던 긍정적인 경험을 정리하는 포스팅입니다. 사실은 테스트 코드 작성 시 효율적인 방법과 팁을 정리하려 했으나 아직 mock을 활용한 테스트에 대한 이해가 떨어지는 것 같아 다음으로 미루고 테스트코드가 어떻게 비지니스 로직을 보호하는지 이야기 하도록 하겠습니다.
테스트틀 통하여 비지니스 이해하기
최근 MockitoExtension를 활용하여 테스트 코드를 작성하고 있습니다. Mock 을 통해 테스트를 진행하면 테스트 하고자 하는 레이어를 부분적으로 빠르게 테스트 할 수 있고, 식스샵 처럼 객체 관계나 데이터베이스의 관계가 복잡하여 테스트하기 어려운 부분을 대체 하여 손쉽게 테스트 할 수 있습니다.
오늘 테스트 코드를 작성할 대상은 제가 작년 9월 작성한 코드로 고객에 이메일을 변경하는 간단한 기능을 제공하고 있습니다.
기존 코드(feat. 레거시) 의 테스트를 작성하면 해당 비즈니스 요구 사항을 명확하게 확인 할 수있게 해주고 작성 된 테스트 코드가 존재하는 경우 비지니스로직을 설명해주는 아주 좋은 문서 역할을 해줍니다.
해당 코드가 가지는 요구사항을 정리하고 테스트 코드를 작성해보았습니다.
- 변경하려는 이메일이 사용중이지 않은경우
- 변경하려는 이메일이 사용중인 경우
먼저 변경 하려는 이메일이 사용중이지 않을 경우 repository.update 가 실행되는 것을 확인(행위검증) 함으로서 해당 서비스가 정상 동작함을 확인 할 수 있습니다.
변경 하려는 이메일을 사용중일 경우 DuplicateCustomerEmailException 을 발생하는지 확인하는 방법으로 테스트 코드를 작성 할 수 있습니다.
작성된 테스트 코드는 비즈니스 요구 사항 나타내는 도큐먼트로 다시 해당 메서드를 수정해야할 상황에서 빠르게 비지니스를 이해 할 수 있도록 활용 할 수 있습니다. 🙌
테스트를 통한 비지니스 보호
테스트 코드를 작성하면서 상당히 거슬리는 코드가 있어 리펙토링을 진행하였습니다.
본인의 상태를 외부로 노출하고 있으며 조건문도 한눈에 알아보기 힘듭니다.
ShopCustomer 객체 내부로 로직을 이동시켜 캡슐화 하였으며 메소드명을 통해 어떤 행동을 하는지 명확하게 나타낼 수 있습니다. (해당 메소드에 대한 테스트 코드는 깃헙 또는 코드를 확인해주세요.)
변경된 코드는 아래와 같습니다.
한결 깔끔해진 코드에 만족하며 핫픽스를 외치며 배포를 요구 합니다.
… 20분 뒤
늘 그렇듯 기대를 배신하고 서비스운영팀에 불을 지르고 맙니다. 😱
물론 서버를 구동하고 사이트에 접속해서 회원가입을 하고 회원정보를 변경해보고 배포를 한다면 위와 같은 문제를 방지할 수 있지만 우리의 환경은 해당 버그를 발견하기 어려운 경우가 많습니다.
서버 구동은 오래걸리고 회원가입을 하고 회원 정보를 변경하는일은 여간 귀찮은게 아닙니다.
심지어 해당 케이스는 해피패스가 아니므로 테스트를 하였음에도 불구하고 놓치는경우도 빈번합니다. 😭
하지만 지금은 테스트코드의 도움을 받을 수 있습니다.
위에 서술한 몇십분이 걸릴지 모르는 귀찮은 테스트 작업을 0.5 초만에 비지니스 로직에 문제가 있음을 확인 할 수 있습니다.
해당 조건문이 가져야하는 조건은 고객의 동등성을 확인하는게 아니므로
와 같이 수정하였고 테스트가 정상 동작하는것을 확인 할 수 있습니다.
이처럼 테스트 코드를 작성하면 서비스 장애를 보다 빠르게 확인하여 실제 서비스가 안정적으로 운영되도록 활용할 수 있습니다.
결론
기존 코드의 테스트 코드를 작성하면서 기존 비지니스를 이해하는데 도움을 받을 수 있었고 서비스에서 발생했을 버그를 사전에 발견할 수 있도록 하여 서비스 운영팀에게 혼날일을 하나 줄일 수 있었습니다. 😆
식스샵 개발팀 여러분도 테스트 코드를 통해 레거시에 대한 이해도를 높히고 버그 걱정에서 벗어나는 행복개발 되시기를 바라봅니다. 😍
