인프런 커뮤니티 질문&답변

안녕하세요, 나민혁 님!

실제 프론트엔드(이하 FE) 개발자 분들과 협업 시, 논의를 통해 다음과 같이 결정할 수 있습니다.

• FE 입장에서 문서만 있어도 충분하다고 하는 경우

  • REST Docs, swagger 등 문서 도구를 사용하고 있다면, 요청과 응답 스펙을 정하고 mock 객체를 만든 뒤, 문서가 잘 생성될 정도로만 최소한의 개발을 진행합니다.

• FE 입장에서 문서 & 실제 요청 후 가짜 응답도 받아볼 수 있으면 좋겠다고 하는 경우

  • 위의 문서 작업 뿐만 아니라, 어느 정도 그럴듯한 케이스를 정해서 실제 개발단계에서 백엔드(이하 BE) 쪽으로 요청을 날렸을 때 가짜 응답이 오도록 구현합니다.

  • (저의 경우) 항상 같은 응답보다 여러 케이스를 제공하는게 좋겠다 싶으면 랜덤으로 다양한 응답이 내려가게 하거나, 특정 조건에 맞게 가짜 응답을 변경하는 등 추가 제공을 하기도 합니다. 물론 전체 구현 일정이 충분한 경우에만 이런 편의를 제공합니다. ㅎㅎ

추가적으로 Domain Entity 설계는 조금 다른 내용인데요. Entity 설계는 BE 단에서 결정해야 하는 상황이기 때문에, 문서를 작성하는 시점에 이미 설계가 완료되었을 수도 있고, 아닐 수도 있습니다.
물론 문서를 제공하기 위해 '어느정도 이럴 것이다~' 정도의 설계는 하고 문서를 작성하기는 하는데요, 설계가 변경될 수도 있으니 스펙의 변동 가능성이 있다면 FE 분들께 미리 양해를 구하는 편입니다.

도움이 되셨기를 바랍니다.
감사합니다 ☺

안녕하세요, 인프런 AI 인턴입니다. 나민혁님, 질문해주셔서 감사합니다. 실무에서 테스트를 시작할 때 mock 객체를 사용해 컨트롤러 테스트를 먼저 작성한다는 것은, 실제 서비스 또는 외부 시스템과의 의존성 없이 컨트롤러(layer)의 로직을 검증하기 위함입니다. 이는 TDD(Test Driven Development)의 초기 단계에서 이루어질 수 있으며, 실제 비즈니스 로직이 구현되기 전에 API 스펙을 먼저 정의하고, 요청과 응답 포맷을 명세화하는 과정에서 REST Docs와 같은 도구를 사용하여 문서화 작업을 병행합니다.

BDDMockito의 given 메서드를 사용하는 것은 테스트 대상 객체가 특정 상황에서 예상되는 동작을 수행하도록 설정하는 과정입니다. 여기서 말씀하신 “메서드는 메서드명과 파라미터, 리턴타입 정도까지만 정해두고 Request와 Response를 정의한다”는 의미는, 실제 구현 로직이 없어도 테스트 대상 메서드의 입출력 스펙을 미리 정의해두고, 이를 바탕으로 테스트 코드를 작성한다는 것입니다. 이 과정에서 Domain Entity는 이미 정의되어 있음을 가정합니다.

REST Docs를 작성할 때는, 질문에서 언급하신 것처럼 요청과 응답의 형태, API가 받을 수 있는 파라미터, 기대하는 응답 코드와 바디 등을 명세해야 합니다. 이를 위해 테스트 코드 내에서 실제 요청을 모의로 수행하고, 기대하는 응답이 반환되는지를 검증하는 작업이 필요합니다. 실제 프로덕션 코드 작성 전에 이러한 문서화 작업을 수행함으로써, API의 스펙을 명확히 하고, 향후 프론트엔드 개발자나 API를 사용하는 다른 개발자들에게 명세를 제공할 수 있습니다.

답변이 도움이 되었기를 바랍니다. 더 궁금하신 사항이 있다면 언제든지 추가 질문해주세요!