전체 테스트 vs asciidoctor 질문

안녕하세요, bamho 님!제가 유추하기로는, asciidoctor의 문제라기 보다는 테스트 검증 방식에 대한 문제일 것 같은데요.deleteAll()이나 deleteAllInBatch()를 사용하더라도 auto-increment로 증가한 DB 테이블의 ID 는 초기화되지 않습니다.전체 테스트에서 해당 엔티티의 ID를 1부터 순차적으로 증가시켰으니 ID 값은 4가 되는 것 같아요.그래서 보통 ID 값이 얼마일 것이다, 라고 직접적으로 숫자 값을 검증하는 것 보다는, 해당 데이터(row)를 특정할 수 있는 비즈니스 키나, given 절에서 세팅한 특정 값이 잘 조회되었는지를 검증하는 것이 좋습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

SpringBootTest 최소화 방법 문의

안녕하세요, 박준수 님!맞습니다. 그래서 저는 Mock 처리가 필요한 클래스들을 전부 @MockBean 설정한 통합 지원 클래스 하나를 두고 공용으로 사용합니다.보통 Mock으로 처리하고자 하는 서비스들은 외부 시스템을 호출하는 등 대부분의 테스트에서 실제 Bean을 사용하지 않는 케이스이기 때문에, IntegrationTestSupport에서 한번에 처리하여 사용하는 편이에요.도움이 되셨기를 바랍니다.감사합니다. 🙂

DTO 생성과 관련해서 궁금한 게 있습니다!

안녕하세요, yg04076 님!DTO 내부에 변환 로직을 두면 서비스는 깔끔해지지 않을까요? AnimalDTO.of(animal, ...) 과 같이 각 DTO에 정적 팩토리 메서드를 만들고, 필요한 정보를 파라미터로 받아 내부에서 변환하도록 하면 될 것 같아요.감사합니다. 🙂

API 명세서 툴 ( Swagger vs Spring Rest Docs)

안녕하세요, bamho 님!같은 프로젝트에서 문서 도구를 2개 이상 쓸 이유는 없어보이고요 ㅎㅎ팀별로 다르게 Swagger를 쓰는 팀도 있고, REST Docs를 사용하는 팀도 있습니다.무엇을 선택하느냐는 각 도구의 장단점에 맞게 선택하면 될 것 같아요.제가 속한 현재 팀에서는 개발 속도를 고려하여 Swagger를 사용하고 있지만, 개인적으로는 테스트 코드 기반의 REST Docs를 사용하는 것을 선호합니다.감사합니다. 🙂

재고 엔티티 설계

안녕하세요, springYam 님!이전에 재고 관련해서 비슷한 질문을 하신 분이 계셔서, 해당 답변 참고하시면 좋을 것 같아요.감사합니다. 🙂

@Builder 관련 문의

안녕하세요, bamho 님!맞습니다. 생성자 대신 Builder를 쓰는 이유는, 빌더 패턴을 통해 각 필드를 명시적으로 표기함으로써 코드의 가독성을 가져가고가 하는 취지에요.보통 실무에서 사용하는 객체는 필드가 수십 개가 넘어가는 경우도 꽤 흔한데요, 생성자로 그 많은 값들을 주입하려면 타입이나 순서를 고려하여 값을 넣어야 하기 때문에 많은 위험을 감수해야 합니다.빌더 패턴을 사용하면 필드명을 보면서 데이터를 명시적으로 주입하기 때문에, 여러 면에서 이점이 있습니다.빌더를 내부에서만 사용하도록 private으로 설정하고, 외부에서는 정적 팩토리 메서드 등으로만 인스턴스를 생성할 수 있도록 하는 방법도 있으니 참고해 주세요.감사합니다. 🙂

@Value 관련 환경변수 주입 테스트코드 질문..

안녕하세요, bamho 님!전체 프로젝트를 확인한 것은 아니지만, 보통 test yml 프로파일에 테스트용 값을 직접 명시하면 Value로 잘 주입될 거예요.차선책으로 해당 객체의 사용처를 고려하여 MockBean 처리를 하는 방법도 있으니 참고해 주세요.감사합니다. 🙂

다른 섹션ppt도 받을 수 있을까요?

안녕하세요, 성관 님!macOS 에서 압축하면서 파일이 깨져서 올라갔나 보네요 ㅠㅠ현상 확인 후 다시 재업로드 하였습니다. 감사합니다 🙂

ResponseDto 위치 질문

안녕하세요, bamho 님!이전 강의 중에 request DTO에 대해, Controller Request에서 Service Request로 변환해준 내용 기억나시나요?Service 레이어가 Controller 레이어에 의존하지 않도록 DTO 간 변환 처리를 해준 것이었는데요.마찬가지 이유로 현재 강의 예제의 Response 객체는 Service에서 만들어지기 때문에, Service 레이어 쪽 패키지에 두고 Controller가 이를 자연스럽게 의존하도록 둔 것이라 이해해주시면 됩니다.레이어 간 의존성의 방향이 한 곳으로만 흐르도록 설계해 준 것이죠.도움이 되셨기를 바랍니다.감사합니다. 🙂

@RestControllerAdvice 와 @Validation

안녕하세요, 조희제 님! 컨트롤러 테스트 할 때 빈 validation이 적용 된 모든 필드를 하나씩 모두 검증 하나요?테스트는 항상 자신이 필요하다고 생각하는 범위에 적용하시면 됩니다.모든 필드를 검증하는 것이 물론 좋으나, 주어진 시간과 필드 중요도에 따라 선택할 수도 있는 것이죠.상황에 맞게 결정하시면 됩니다.저도 시간이 충분하다면 최대한 많이 검증하는 방향으로 테스트를 작성합니다. 공통 예외 처리는 어떻게 하는게 좋을까요?특수한 경우가 아니면 도메인 Controller 별로 Advice를 두기 보다는, 공통 Advice 하나에서 우리 시스템의 에러 응답 포맷과 정책을 관리하는 편입니다.보여주신 예시에서는 GeneralAdvice 하나만 관리하는 형태인 것이죠. 도움이 되셨기를 바랍니다.감사합니다. 🙂