커버리지는 어떻게 활용하시는지 궁금합니다.

안녕하세요, seonrizee 님!저는 다음과 같이 생각합니다.커버리지 자체를 중요하게 신경쓰는 것 보다는 중요도에 따른 도메인/비즈니스 로직에 집중하여 테스트 코드를 작성하는 것이 맞다.다만, 팀 내에서 커버리지 자체에 대한 최소 기준을 가져가는 것은 팀원 모두가 의식적으로 테스트 코드를 꾸준히 작성하게끔 하는 동력이 될 수 있다.ex. 우리 팀의 최소 라인 커버리지는 60%로 정한다. (향후 커버리지가 더 좋아지면, 65, 70% 로 높여서 적용해나갈 수도 있음)감사합니다. 🙂

테스트 문서화 질문입니다

안녕하세요, save 님!테스트 코드 자체를 굳이 문서화하지는 않습니다. 이미 테스트 코드 자체가 문서의 기능을 하고 있기 때문입니다. ㅎㅎ도움이 되셨기를 바랍니다.감사합니다. 🙂

단위테스트 질문이 있습니다

안녕하세요, woo93xna 님!상황에 따라 다른데요. 예를 들어 만약 native query로 직접 구현한 CRUD 기능이라면 당연히 내가 작성한 기능이니 테스트가 필요할 것이고요.JpaRepository 같이 이미 라이브러리 단에서 보장된 기능은 (물론 테스트 해도 되지만) 굳이 테스트하지 않으셔도 괜찮습니다. 우리에게 중요한 것은 시간이고, 그 시간에 상대적으로 더 중요한 테스트에 힘을 쏟는 것이 이득이기 때문입니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

컨트롤러는 모킹을 한 이유가 궁금합니다.

안녕하세요, jaljayo85 님!Controller 계층은 보시다시피 매우 얇은 계층으로, 비즈니스 로직이 없고, 파라미터의 검증 정도만을 담당하고 있습니다. 따라서 Controller를 테스트하고자 할 때는 상대적으로 무거운 비즈니스 로직을 담고 있는 Service를 mocking하는 것이 적절한 판단이라고 생각합니다.반면 Service, Repository 는 두 레이어가 연합하여 비즈니스 로직을 전개하고 있으므로, (Repository의 기능도 단독 테스트로 보장함과 동시에) 통합 테스트를 작성하여 원하는 요구사항을 반영하고 있는지를 테스트한다고 이해해주시면 되겠습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

ERD 가장자리에 있는 도메인 테스트 질문

안녕하세요, 김혁준 님!네, 맞습니다. 엮여 있는 도메인이 많을수록 벌어질 수밖에 없는 상황이기에, 아래와 같은 방법을 사용해보시면 좋습니다.테스트 클래스 내에서 중복 로직 추출 (적절한 관리가 가능하다면) fixture 를 쉽게 만들 수 있는 유틸 클래스 추가 및 이용예를 들어 C 도메인을 만들기 위해 A, B 도메인이 순차적으로 필요한 상황에서, 대부분의 테스트에서 A, B가 크게 달라지지 않는다면 위와 같은 방법을 사용해 생산성을 높여볼 수 있을 것 같아요.다만, 너무 많은 정보를 함축하여 테스트 코드를 읽을 때 어려움이 생기는 상황은 잘 피해서 도입하는 것이 좋겠습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

자바 record 사용에 대해서 질문 드립니다!

안녕하세요, 이찬원 님!좋은 질문이네요. record는 본질적으로 DTO와 VO에 사용되며, 말씀하신대로 불변성을 보장하면서 사이드이펙트를 줄여주는 역할을 하는데요.언제 record를 쓰고 언제 class를 사용해야하는지 명확하게 지침을 세우기는 조금 어렵지만, 이미 잘 알고 계시는 것처럼 해당 객체가 불변성을 뛰어넘어 상태가 변하는 등의 기능을 가지게 된다면 class로 변경할 것 같아요. 아마 record의 기능을 확장하시면서 한계가 느껴졌다는 부분이 이런 부분 아니었을까 싶네요 ㅎㅎ감사합니다. 🙂

DTO 검증 필드에 대한 테스트 코드 작성은 어디까지?

안녕하세요, 최근호 님!테스트 코드는 다다익선이지만, 상황과 자원에 맞게 필요하다고 생각하는 정도로 적용하시면 됩니다.항상 모든 필드에 대해 검증하는 것이 어려울 수 있으니, 정말 중요한 몇몇 필드에 대해서 검증하도록 하는 것도 좋은 방법입니다.감사합니다. 🙂

OrderCreateRequest DTO에 대해서 궁금한점

안녕하세요, 최근호 님!말씀하신 방법도 적절한 방법입니다. 상황에 따라 선택하시면 되는데요.강의 예제에서는 productNumber도 id처럼 유일성을 보장하고, 특정 상품을 의미하는 비즈니스 키로 사용되고 있기 때문에 역할은 동일합니다.만약 내부 id 값이 외부에 노출되어서는 안 되거나 하는 등의 상황에서는 비즈니스 키를 사용하는 경우도 있으니 참고해 주세요.감사합니다. 🙂

고전파의 테스트 대역 사용 대상, 공유 의존성

안녕하세요, 김상형 님!인프런 AI 인턴도 답변을 잘 해준 것 같은데요.고전파의 사상을 따르자면 공유 자원인 데이터베이스에도 테스트 대역을 사용하거나, 실제 프로덕션에서 사용하는 데이터베이스 환경(ex. MySQL)을 구성하여 테스트하는 것이 좀 더 자연스러울 수 있으나, 강의에서 채택한 방식은 일종의 트레이드-오프 라고 볼 수 있는데요.좀 더 정리해보자면, 제가 지향하는 바는 우리 시스템에서 사용하는 데이터베이스가 예측 불가한 공유 자원이 아닌, 예측 가능한 자원이라고 생각하는 쪽이에요. (같은 시스템(계) 내부라고 생각. 그래서 내가 온전히 제어할 수 없는 외부 시스템(메일)에 대해서만 대역 처리를 한 것이고요.)그래서 테스트 대역이 아니라 실제 DB를 사용하고자 했고, 다만 실제 DB보다 조금 더 효율적이라고 생각하는 H2 DB를 사용하게 된 것이라 이해해주시면 되겠습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

강의 내용 정리 및 자료 제작 툴 문의 드립니다.

안녕하세요, shsf 님!네, 출처를 밝히고 기재하셔도 괜찮으나, 강의의 너무 상세한 내용이 다 드러나는 것은 지양 부탁드리겠습니다. 🙂강의 툴은 애플의 키노트 사용하고 있어요.감사합니다!