인프런 커뮤니티 질문&답변
작성한 질문수
.png?w=112&f=avif)
테스팅 방법론에 관한 질문 드립니다
해결된 질문
작성
·
187
1
테스팅을 하려다 보니 복잡하기도 하고, 긴가민가한 부분들이 있어서
아직 수업에서 다루지 않은 부분이지만 질문을 드리게 되었습니다.
만약 모두 작성한다면, controller -> service -> repository 순으로 테스트코드를 작성하시나요?
그렇다면 이와 같은 경우에서 controller.spec.ts에서 status code나 json body에 대한 테스트 케이스는 만들지 않고,
filter나 interceptor의 테스트 코드를 작성하고, 여기서 status code와 return되는 json body를 다루면 될까요?
argument가 service layer로 전달되는 것만을 테스트하면 되는 걸까요?
답변 1
2
안녕하세요 김종연님!
좋은 질문 감사합니다.
1. 저는 사실 결제나 특수 도메인 말고는 TDD를 적용하지 않습니다. TDD를 적용할때에는 개인적으로 아래에서 위로 적용하는 편입니다. repository -> service -> controller 식으로요! 또한 적용한다면 service 로직에 fake repository를 사용해서 테스팅하고 controller에서는 e2e 테스트처럼 http 요청과 응답에 대해 테스팅하는 편입니다. 물론 필요에 따라 controller에서도 fake service를 두고 테스팅하는 경우도 있습니다.
2. 말씀해주신 방법도 좋은 방법인 것 같습니다! 저는 1에서 말씀드렸던 것처럼 컨트롤러에서 e2e 테스팅처럼 http 요청과 응답 방식으로 테스팅을 하는 편입니다. 그러면 응답 기대값이 인터셉트가 적용된 데이터이기에 status와 함께 한 번에 테스팅을 하는 것이죠. 물론 인터셉터 자체도 fake 데이터를 두고 테스팅할 수도 있습니다.
(추가적으로 테스팅 관련 내용은 아니지만, 고양이 프로젝트에서 전체에 적용되는 데이터 변환 인터셉터({ success : true, data : ... })는 강의 설명을 위해 적용한 경우이고 프로젝트마다 다르겠지만 대부분 하나의 컨트롤러 라우터에 대해 필요 시에 데이터 변환용 인터셉터를 답니다. 실제 프런트엔드에서 받을때 success: true or false는 이미 예상을 하고 있는 경우가 많기 때문이죠.)
3. 만약 컨트롤러에서 http 요청, 응답 방식으로 테스팅을 하지 않는다면 fake service를 두고 service layer에서 전달받은 것만을 테스트하는 것이 좋을 것 같습니다. 인터셉터는 또 들어오는 fake data를 두고 테스트 하는 것이죠.
추가적으로 궁금한 사항 있으시면 답글 남겨주세요!
명쾌한 답변 감사합니다. 말씀해주신대로 한번 진행해보겠습니다 !