Skip to content

[테스트 코드] 테스트 코드를 작성하는 이유

이은비 edited this page Mar 28, 2023 · 1 revision

테스트 코드를 작성을 시작하게 된 계기

프로젝트 초기 세팅에서 프론트엔드 측과 공유할 API 명세 방식으로 Swagger와 RestDocs를 고민하였습니다. 각각은 장단점이 존재하면, 두 가지 모두 많이 쓰이는 라이브러리입니다.

Swagger는 웹을 통해 접근할 수 있으며, 프론트엔드 측에서 직접 테스트를 진행할 수 있습니다. 하지만, Swagger-ui에 노출되도록 하기 위해서는 운영 단계에서 사용하는 코드와 결합이 되어야 합니다. ( 개인적으로 이는 코드의 가독성을 해친다고 생각합니다. )

RestDocs 역시 웹을 통해 접근할 수 있고, 파일 형식으로 공유할 수도 있습니다. 단, 프론트엔드 측에서 직접 테스트를 진행할 수는 없습니다. 이 말은 곧 서버 쪽에서 테스트 작업이 선행되어야 함을 의미합니다. Controller 단위의 테스트 코드 작성으로 성공한 테스트에 대해서만 API 명세가 가능합니다.

위의 2가지 특징을 비교했을 때, RestDocs를 사용하면 비즈니스 로직 개발과 동시에 검증이 함께 이루어질 수 있으므로 로직의 안정성이 확보될 것이라 판단했습니다. 따라서 주말의집 프로젝트에서는 RestDocs를 이용해 API 명세를 진행합니다. 해당 명세서는 README 파일에 참조된 링크를 통해 확인 가능합니다.

테스트 코드 작성으로 얻은 인사이트

API 명세를 위해서는 Controller 단위의 테스트 코드 작성만 이루어지면 됩니다. POSTMAN 도구를 이용해 로컬 환경에서도 테스트를 진행하지만, MockMvc를 통해 코드 상에서도 동일한 결과를 얻을 수 있는지 이중 확인 작업이 이루어지면서 코드의 안정성을 확보할 수 있음이 코드에 대한 신뢰성을 높여주었습니다.

Controller 단위 테스트는 단순히 HTTP Method, URI, DTO에 대한 검증이 이루어집니다. 여기에 더 나아가 비즈니스 로직에 대한 신뢰성도 확보하고자 Service 계층의 단위 테스트도 진행하기로 했습니다.

비즈니스 로직을 검증하기 위해 성공 케이스와 실패 케이스에 대해 발생할 수 있는 경우를 떠올리고 이를 코드로 작성하여 검증하였습니다. 이 과정에서 로직 혹은 객체 간의 결합도 높아 테스트가 어려워지는 경우에는 비즈니스 로직을 재점검하는 포인트가 되었습니다.

신뢰성 높은 로직과 결합도가 낮은 코드를 작성하도록 끊임없이 고민하게 한다는 점에서 테스트 코드 작성은 필요한 과정이라고 생각합니다. 😊

Clone this wiki locally