계층 관련 질문이 있습니다.

안녕하세요, 압구정 자발개 님!네, 맞습니다. 강의 예제는 간단한 프로젝트이기 때문에 Service에서 반환하는 Response를 그대로 사용했는데, 이대로도 사실 의존 관계 상 큰 문제는 없습니다.만약 실제 최종 응답에 사용되는 형태와 Service에서 반환하는 데이터의 형태가 달라야 한다면, 각 레이어에 DTO를 별개로 두고 변환 과정을 거쳐야 할 거예요. (강의 중에 Request가 계층을 넘어오면서 변환 과정을 갖도록 했던 것 처럼요.)도움이 되셨기를 바랍니다.감사합니다. 🙂

'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다

안녕하세요, eomuksoyummy 님!저도 말씀하신 방법처럼 하고 있어요.자바에서 Builder를 사용하는 이유 중 하나는 파라미터를 단순 순서가 아닌 이름 기반으로 매칭하여 가독성을 높이고 실수를 줄일 수 있다는 것인데요.코틀린에서는 생성자 단에서 이름 기반 매칭을 지원하기 때문에, 생성자를 활용하면 충분히 같은 효과를 가질 수 있습니다.추가로 코틀린에서의 Fixture 정의가 필요한 경우도 생각해볼 수 있는데요. 만약 실제 프로덕션 생성자에서는 A라는 파라미터가 필수값일 수 있는데, 테스트코드에서는 A라는 파라미터가 주어지지 않으면 특정 값이 기본 값으로 설정되도록 미리 정의해둘 수도 있습니다.팩토리 메서드를 정의했다고 해서 반드시 생성자를 private으로 둘 필요는 없으니, 언어의 특성에 맞게 (명확한 이유가 있는) 컨벤션을 정하고 적용해보면 좋을 것 같네요.도움이 되셨기를 바랍니다.감사합니다. 🙂

혹시 update 로직은 어떻게 테스트하나요? (@Setter?)

안녕하세요, ewgregerg c 님!강의에서도 말씀드렸지만, 테스트 코드만을 위한 프로덕션 코드 작성은 지양해야 합니다.말씀하시는 update가 JPA의 변경 감지 기능을 테스트하는 것이라면, Service 테스트에서 트랜잭션 기반으로 변경 쿼리가 수행되고 잘 반영되는지를 테스트해볼 수 있겠네요.감사합니다. 🙂

학습용 java/spring 오픈소스 추천

안녕하세요, BuildYourProgram 님!특정 오픈소스를 추천드리기는 조금 어려울 것 같고, 저는 다음과 같이 접근하는 편이에요.Spring 프레임워크의 코드 살펴보기 (내가 사용하는 기능 위주로)현재 사용하고 있는 라이브러리가 있다면, 필요한 경우 내부 코드 살펴보기어떤 오픈소스를 정해서 살펴봐야겠다, 보다는 현재 내가 사용하고 있는 라이브러리나 프레임워크를 중심으로 살펴보는 것이 제일 좋다고 생각합니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

단위테스트와 통합테스트의 경계가 궁금합니다.

안녕하세요, rlamw2000 님!네, 맞습니다. 저는 통합 테스트란 어떤 계층부터 어떤 계층까지 테스트하는 것이다, 라고 정의하기 보다는, 둘 이상의 모듈을 묶어서 테스트하면 통합 테스트라고 생각하고 있어요.그래서 컨트롤러부터 리포지토리까지 전부 테스트하는 것도 마찬가지로 통합 테스트라고 생각합니다.단위 테스트는 독립적인지가 가장 중요한데요, 사실 그래서 강의에서 보여드린 컨트롤러 테스트와 리포지토리 테스트는 스프링을 띄워서 테스트하는 관점으로 보았을 때 엄밀히 통합 테스트겠지만, 서비스 레이어의 통합 테스트와 비교하였을 때 다른 계층이 관여하지 않는 다는 의미에서 "단위 테스트 느낌이 나는" 테스트라고 설명 드렸습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

Service+Repository 통합테스트 관련 질문입니다.

안녕하세요, hwang99 님! 1. 계층별 테스트 분리 기준에 대한 질문입니다.컨트롤러, 레포지토리는 단위테스트, 서비스 계층은 레포지토리 부분과 통합테스트 이렇게 분리해서 진행하셨던 이유를 여쭤봐도 될까요?2가지 관점일 것 같은데요. 첫 번째로 서비스 단위테스트를 하지 않았던 이유는, 말씀하신 것처럼 FakeRepository를 구성하는 리소스 대비 효과가 적다고 생각하기 때문입니다.두 번째로 서비스 레이어에서 통합 테스트를 진행한 이유는, 비즈니스 로직은 서비스 레이어부터 시작하기 때문입니다. 컨트롤러는 사실 (현재 구조에서는) 얇은 층이고, 담당한 역할이 외부 세계와의 소통, 최소한의 데이터 신뢰도 보장 정도이기 때문에 단위 테스트로도 충분하다고 생각해요.물론 여기에 더해 모든 층을 아울러서 테스트하는 통합 테스트, 더 나아가 인수 테스트도 할 수만 있다면 좋은 것이고, 복잡한 사용자 시나리오일수록 꼭 필요한 상황도 있다고 생각합니다. 2. 통합테스트 DB 관련 질문입니다.서비스계층과 레포지토리 계층을 묶은 상태로 H2 같은 임베디드 데이터베이스를 사용하면 테스트 속도가 상당히 느리게 나오긴 합니다. 이런 부분은 어쩔 수 없이 안고 가는 것인가요? 그리고 운영이나 개발 DB를 postgress같이 H2말고 다른 걸 사용한다고 해도, H2로 통합테스트 테스트하는게 이점이 있을까요?만약 항상 구동 중인 개발 DB에 테스트할 수 있다면 속도는 빠르겠으나, 여러 사람이 테스트할 경우 그 독립성을 보장해줄 수 있는 환경이어야만 할 것입니다.시간과 공간의 제약을 고려하고 독립성을 보장하면서, 그나마 빠른 인메모리 데이터베이스로 H2가 가장 적당하다고 생각합니다.물론 운영 DB와 H2와의 차이점 때문에 테스트가 어려운 케이스도 가끔 있습니다만 (ex. 스키마 차이) 그런 경우는 트레이드 오프로 감안하거나, 꼭 필요한 테스트 케이스라면 해당 케이스만 실제 운영 DB와 같은 종류의 DB를 구축하여 테스트하는 방식도 있겠습니다. 3. 서비스 계층 단위테스트 관련 질문입니다.혹시, 부담이 안 된다면, 서비스 계층의 단위테스트가 중요도가 많이 떨어진다고 생각하시는 이유가 Fake든 Mockito를 사용한 Stub이든 데이터베이스를 흉내만 내는 테스트가 의미가 없다고 여기셔서 그런 것일까요?저는 FakeRepository가 존재하는 프로젝트를 다룰 때, 매번 Repository 메서드를 하나씩 추가할 때마다 FakeRepository도 유지보수를 해야 해서 힘들었던 경험이 있는데요. 테스트만을 위한 코드를 작성한다는 느낌을 지울 수가 없었습니다 ㅎㅎ물론 서비스 계층의 단위 테스트를 할 수 있다는 장점이 있겠지만, 제가 느끼기에는 FakeRepsitory를 관리하는 만큼의 효용은 없었던 것 같아요.도움이 되셨기를 바랍니다.감사합니다. 🙂

OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요

안녕하세요, ewgregerg c 님!AI 인턴이 잘 설명해준 것처럼, LocalDateTime의 직렬화 문제인데요. 설명에 나와있는대로 ObjectMapper의 설정을 해주시면 해소가 될 것으로 보입니다.감사합니다. 🙂

test 용 .yml

안녕하세요, highjune 님!예시 프로젝트는 크기가 작기 때문에 별도 분리를 하지 않았는데요. 프로젝트가 복잡해짐에 따라 테스트 코드의 설정 파일을 별도로 두는 방법도 좋습니다. 다만, 프로덕션에서 사용하는 설정이 변하는 경우 같이 관리를 해주어야 한다는 단점이 있기 때문에 상황에 따라 잘 선택하시면 될 것 같아요.감사합니다. 🙂

throws Exception

안녕하세요, highjune 님!AI 인턴이 설명을 잘 해주었는데요, 테스트 코드에서는 테스팅하고자 하는 대상과 행위가 무엇인지에 따라 선택과 집중을 하는 것이 좋습니다. throws Exception으로 처리한 테스트 코드는 예외의 종류 자체가 중요한 테스트 케이스는 아니었을 것이고, 만약 테스트 코드가 checked exception에 대한 테스트를 하는 케이스였다면, 그에 대해 처리를 했을 것입니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

카페키오스크 클래스 문의 ,,

안녕하세요, itboxer91 님!앞 부분 강의를 살펴보시면 add() 메서드가 2개인 것을 확인하실 수 있습니다.감사합니다. 🙂