Pull Request 026. 자유 게시글 테스트 코드를 리팩토링하며 느낀 점
자유 게시글에 헥사고날 아키텍처를 적용하면서, 많은 클래스의 변동이 일어났다. 이에 맞춰 테스트 코드도 리팩토링해야 한다.
크게 달라진 것은 없다. 로직 자체가 많이 바뀌지 않았기 때문에, 테스트 코드 작성도 전과 비슷한 맥락에서 진행되었다. 그럼에도 가장 크게 느낀 점 몇 가지를 기록해보고자 한다.
먼저, DTO를 많이 사용하는만큼 테스트 코드의 길이가 길어졌다. 기존에는 하나의 DTO를 여러 계층에서 사용했기 때문에 테스트 코드에서도 많게는 2개, 적게는 1개 정도의 DTO만을 만들어서 사용했다. 그러나 Client -> API / API -> Client / API -> Application / Application -> API / Application -> Persistenct / Persistenct -> Application 이렇게 총 여섯개의 DTO를 사용하게 되니 당연히 그만큼 테스트 코드도 길어지더라.
또한 기존의 여러 책임을 물던 서비스 계층 / API 계층의 객체들을 각자 하나의 책임들만 물 수 있게끔 수정하니 그만큼 테스트 해야할 클래스들이 많아졌다. 클래스가 많아졌다는 건 그만큼 코드가 많이 발생한다는 것이다.
그러나 결과물을 놓고 보았을 때는 오히려 전보다 나았다. 하나의 테스트 메서드의 코드는 길어졌지만, 테스트 클래스의 코드는 짧아졌다. 당연하다. 여러 책임을 물던 클래스는 그만큼 여러 기능이 있었고 그만큼 많은 테스트 코드가 발생한다. 예를 들어 FreeBoardCommandService의 경우에는 수정 / 삭제 / 저장의 세 가지 책임을 모두 물었기 때문에 세 기능에 대한 테스트를 모두 한 테스트 클래스에 저장했다. DisplayName을 일일이 찾는 것은 귀찮은 일이었다.
높아진 시스템 복잡도를 직접 체감할 수 있는 기회이기도 했다. 여러 클래스의 테스트 코드를 동시에 작성하다보니 어느 클래스에 어떤 필드를 주입해주어야 하는지 계속 헷갈렸다. 나중에는 화면을 반반 분할해서 주입이 필요한 클래스들을 확인하면서 테스트 코드도 작성했다. '굳이 지금의 작은 서비스에서 이렇게까지 해야하나?' 싶긴 했지만, 결국 아키텍처 개선은 필요했고 추후 더 큰 서비스를 만져볼 때 그래도 조금이나마 눈에 익은 상태로 적응하려면 필요한 리팩토링이었다.
여간 귀찮은 일이 아니었지만, 그럼에도 반드시 필요한 일이었고 다 끝내고 나니 꽤 뿌듯한 일이었다. 앞으로 진행할 나머지 작업들에는 그래도 테스트 코드를 재활용할 수 있는 부분이 많아 다행이라고 생각도 되고... 그럼에도 이번 과정을 통해 조금 더 테스트 코드, 헥사고날 아키텍처와 친해졌다는 수확을 얻을 수 있어 다행이라고 생각한다.
전체 코드는 링크에서 확인할 수 있다.