Execution failed for task ':test'. > There were failing tests. See the report at: file:///E:/%EA%B9%80%EC%98%81%ED%95%9C%20%EC%8A%A4%ED%94%84%EB%A7%81%20%EA%B8%B0%EB%B3%B8/core/build/reports/tests/test/index.html * Try: > Run with --scan to get full insights. BUILD FAILED in 8s 4 actionable tasks: 2 executed, 2 up-to-date gradle 도 최신 버전이고, 강의와 똑같이 쳤는데 다음과 같이 나와요 ㅠ 학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요.
강의에서는 @RequestParam의 defaultValue 파라미터가 빈 문자열을 처리한다고 했는데, empty 값만 처리해주는 지 또는 blank도 처리해주는지의 여부가 궁금합니다. 또한, @RequestParam으로 오는 데이터가 blank일 수도 있는데, required = true 옵션은 blank를 인식할 수 있나요?
Actuator, 프로메테우스, Grafana를 통해 운영 서버 모니터링 대시보드를 구축하려고 합니다. (CloudWatch는 일정 용량 이후 비용이 부과되는 문제로 Prometheus를 선택했습니다.) 근데 운영 서버에서 Actuator와 프로메테우스 서버를 띄우면 외부에서도 Actuator 가 제공하는 메트릭 정보뿐만 아니라, 프로메테우스가 수집한 정보를 9090 포트 번호를 통해 접근 가능하다고 생각하였습니다. 처음에는 Actuator의 정보를 ADMIN 권한을 가진 관리자만 접근 가능하도록 설정하였지만, Prometheus 서버에서 접근이 불가능한 문제가 생겼습니다. Prometheus와 Grafana를 통해 모니터링을 구축할 때, 데이터에 대한 보안을 강화할 수 있는 방법이 뭐가 있는지 궁금합니다.
안녕하세요 토비님 어플리케이션 계층의 port는 도메인과 외부의 연결을 위해 필요 하다고 알고 있는데 jpa나 마이바티스 같은 기술 또한 도메인 외부의 내용이기에 인프라 계층으로 들어간다고 알고 있습니다 그런데 의존성 역전을 위한 레파지토리 인터페이스를 어플리케이션 계층에 만들면 어플리케이션 서비스에서 도메인에 관련된 내용을 너무 깊게 관여하는 것 같아서 질문 드립니다 어플리케이션과 도메인의 경계를 어디까지로 보는게 좋을까요
class Controller, class Service, Interface Repository, class RepositoryImpl, Interface JpaRepository의 그림에서 Interface Repository 가 Persistence 가 아닌 Business 계층으로 분리하신 이유가 궁금합니다!
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 영한님이 영상에 addForm을 고친것 처럼, editForm을 고쳐서 수정에서 값이 없으면 에러를 출력하려고 했습니다. 그러나 대실패 입니다. 현재 실력으로는 어떻게 고쳐야 해야 하는지 몰라서 게시판에 도움을 요청합니다. 혹시 힌트라도 주실수 있으신가요? v1컨트롤러 edit 고친것 (add내용을 복사 붙여 놓기 한 다음 수정) editForm을 수정한 내용 (addFrom 의 내용을 수정) 오류 내용 잘린 메시지 Error resolving template [validation/v1/items/{itemId}/edit], template might not exist or might not be accessible by any of the configured Template Resolvers Error resolving template [validation/v1/items/{itemId}/edit], template might not exist or might not be accessible by any of the configured Template Resolvers] with root cause (그 외의 것들은 전혀 건들지 않았음) 힌트를 주실 분 계신가요? 답변 부탁 드립니다.
안녕하세요. 강의 수강중에 의존성 추가에 대해서 의문이 들어 질문드립니다. 제가 26강까지 듣고 올리는 질문이라 후속 강의에서 리팩토링 되는 것이라면 넘어가주세요! 멀티모듈 프로젝트에서는 각 모듈이 각자의 의존성을 갖고 관리하도록 하는 것으로 이해하고 있었는데요. 현재 강의에서는 아래 의존성들이 여러 모듈에 흩어져있습니다. 이렇게 되면 의존성 관리 포인트가 늘어나 단점이 생길 것 같은데요. 하나의 모듈에서 각자의 역할과 책임에 맞게 의존성을 관리하는 것에 대해 강사님의 생각이 궁금합니다! spring data jpa bank-domain bank-event resilience4j bank-core bank-api 만약 위의 의존성들이 각자의 모듈에서 관리된다면 다른 모듈에서 사용할 수 있도록 특정 기능들을 wrapping 해서 제공해주는 방법이 맞을까요? 아니면 혹시 더 좋은 방법이 있을지 궁금합니다. spring data jpa bank-domain 에서 save() , 혹은 findById() 를 다른 모듈에서 사용할 수 있도록 인자만 받는 메소드를 제공한다면 bank-event 에선 id값 혹은 entity형식의 객체(필요시 model or dto 추가)만 넘겨 처리할 수 있으니 spring-data-jpa 의존성을 끊을 수 있을 것 같아서요.
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 2-10 여기까지 이해하신 내용은 무엇인가요? 2. 어려움을 겪는 부분 어느 부분에서 막히셨나요? 코드의 어떤 로직이 이해가 안 되시나요? 어떤 개념이 헷갈리시나요? 3. 시도해보신 내용 문제 해결을 위해 어떤 시도를 해보셨나요? 에러가 발생했다면 어떤 에러인가요? 현재 작성하신 코드를 공유해주세요 강의 잘 보고 있습니다. 이전 강의에서 로컬이 아니라, 리소스가 제한된 클라우드 환경에서 성능 테스트를 하는 것이 좋다고 이해했습니다. 그런데 인텔리제이에서 제공하는 Profile이 기능은 클라우드 환경에서는 따로 사용할 수가 없지 않나요?? 해당 기능을 어떻게 클라우드 환경에서 애플리케이션 성능 측정을 위해 사용할 수 있을까요? 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!
안녕하세요 토비님 회원 애플리케이션 서비스 테스트 (2) -25:19 에 대해 질문 드립니다. record 에 @Transactional을 사용하면 실행에는 문제가 없으나 인텔리제이에서 Classes annotated with '@Transactional' could be implicitly subclassed and must not be final 이와같은 경고 메세지를 주는데 무시하고 지나가도 되는건지요?
토비님 안녕하세요. 39. 문서와 코드 다듬기 강의의 updateInfo 테스트 부분 질문이 있습니다. 강의 28:30 부근에서 updateInfoFail() 에 코멘트를 달게 되는데 성공케이스에 대한 코드는 updateInfo() 부분으로 옮기는 것도 좋아보이는데 토비님 생각이 궁금합니다 . updateInfoFail() 의 마지막에 member 가 member2 의 프로필 주소와 중복되는 테스트가 있으므로, member2 의 프로필 주소를 설정해주는 코드가 필요하지만, 하나만 있어도 괜찮지 않을까 생각합니다. 그래서 나머지 성공에 대한 코드는 updateInfo() 메소드로 옮겨 "상세 정보 수정이 가능한 경우"들을 나열하는게 좋다고 생각했습니다. 똑같은 준비작업이 반복되다보니 한 번 세팅해놓고 여러 케이스를 다 검증해보는 것이 낫다고 하셨는데, 현재 테스트 클래스 메소드가 성공/실패로 나뉘어져있어 성공하는 부분은 다른 메소드로 이동하는게 좋아보인다 생각했습니다. 아래 코드에서 성공 케이스와 실패 케이스로 나누어보았습니다. 코드 updateInfo() @Test void updateInfo() { Member member = registerMember(); Long memberId = member.getId(); memberRegister.activate(memberId); entityManager.flush(); entityManager.clear(); var updateRequest = createMemberInfoUpdateRequest(); member = memberRegister.updateInfo(memberId, updateRequest); assertThat(member.getDetail().getProfile().address()).isEqualTo(updateRequest.profileAddress()); // 기존 프로필 주소로 계속 변경 요청 가능 memberRegister.updateInfo(memberId, updateRequest); // 다른 프로필 주소로 변경 가능 memberRegister.updateInfo(memberId, createMemberInfoUpdateRequest("omg123")); // 프로필 주소 제거 가능 memberRegister.updateInfo(memberId, createMemberInfoUpdateRequest("")); } updateInfoFail() @Test void updateInfoFail() { Member member = registerMember(); Long memberId = member.getId(); memberRegister.activate(memberId); member = memberRegister.updateInfo(memberId, createMemberInfoUpdateRequest()); Member anotherMember = registerMember("another@email.com"); Long anotherMemberId = anotherMember.getId(); memberRegister.activate(anotherMemberId); entityManager.flush(); entityManager.clear(); // anotherMember가 member와 프로필 주소 중복 MemberInfoUpdateRequest duplicateProfileUpdateRequest = createMemberInfoUpdateRequest(member.getDetail().getProfile().address()); assertThatThrownBy(() -> { memberRegister.updateInfo(anotherMemberId, duplicateProfileUpdateRequest); }).isInstanceOf(DuplicateProfileException.class); // member와 중복되지 않는 프로필 주소로는 변경 가능 MemberInfoUpdateRequest updateRequest = createMemberInfoUpdateRequest("profile123"); memberRegister.updateInfo(anotherMemberId, updateRequest); // member가 anotherMember와 프로필 주소 중복 assertThatThrownBy(() -> { memberRegister.updateInfo(memberId, updateRequest); }).isInstanceOf(DuplicateProfileException.class); } 좋은 강의 해주셔서 감사드립니다!
REST API로 서비스를 설계할 경우, 사용자는 보통 프론트엔드를 통해 백엔드의 기능을 이용하게 됩니다. 이때 프론트엔드와 백엔드 각각에 MVC 패턴이 적용된다고 보아야 할까요, 아니면 두 계층을 합쳐 하나의 MVC로 이해해야 할까요? 또한 백엔드 측의 API를 Open API 형태로 외부에 공개한다면, 이것도 뷰로 간주할 수 있는지 궁금합니다.
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 4-8 여기까지 이해하신 내용은 무엇인가요? mysql 내부에서 자체적으로 공유락과 배타락을 사용 2. 어려움을 겪는 부분 어느 부분에서 막히셨나요? 코드의 어떤 로직이 이해가 안 되시나요? 어떤 개념이 헷갈리시나요? 코드상에서 직접적으로 락을 사용하지 않아도 결론적으로 mysql 내부에서 락을 사용하는데 왜 동시성 테스트는 실패하는건가요?? 3. 시도해보신 내용 문제 해결을 위해 어떤 시도를 해보셨나요? 에러가 발생했다면 어떤 에러인가요? 현재 작성하신 코드를 공유해주세요 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] build.gradle 이렇게 하면 되는건가요? 옆에 주석을 써봤는데 제가 이해한게 맞나요? plugins { id 'java' id 'org.springframework.boot' version '3.5.4' id 'io.spring.dependency-management' version '1.1.7' } group = 'hello' version = '0.0.1-SNAPSHOT' java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter-thymeleaf' implementation 'org.springframework.boot:spring-boot-starter-web' // 추가 여기부터 implementation 'com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.1' // SQL 쿼리를 로그로 찍어주는 라이브러리. 개발할 때 DB에서 어떤 쿼리가 실제로 나가는지 확인하기 위함. runtimeOnly 'com.h2database:h2' // H2 DB (인메모리 DB) 사용. 개발이나 테스트용으로 DB 서버 없이 DB를 돌릴 때 편리. // lombok 관련 compileOnly 'org.projectlombok:lombok' annotationProcessor 'org.projectlombok:lombok' testCompileOnly 'org.projectlombok:lombok' testAnnotationProcessor 'org.projectlombok:lombok' // querydsl 추가 implementation 'com.querydsl:querydsl-jpa:9.8:jakarta' // QueryDSL JPA 핵심 라이브러리 annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta" // 엔티티로부터 Q클래스 자동 생성 annotationProcessor "jakarta.annotation:jakarta.annotation-api" // 컴파일 시 필요한 annotationProcessor "jakarta.persistence:jakarta.persistence-api" // Jakarta EE API // 여기까지 // test lombok testImplementation('org.springframework.boot:spring-boot-starter-test') { exclude group: 'org.junit.vintage', module: 'junit-vintage-engine' } // 중괄호 추가 testRuntimeOnly 'org.junit.platform:junit-platform-launcher' } tasks.named('test') { useJUnitPlatform() } // 추가 clean { delete file('src/main/generated') }
안녕하세요. 강의 14분쯤에 말씀해 주신 dirty cheking에 대해서 질문드립니다. order.cancel(); 호출하면, Order의 status 변경되고, 이는 dirty cheking으로 인해 Order에 대해서 update 쿼리가 발생하고, orderitem.cancel()호출하면, Item의 stockQuantity가 변경되고, 이는 dirty checking으로 인해 Item에 대해서 update쿼리가 발생한다. 기본편 및 강의 내용에 대해서 생각해보다가 이렇게 생각했는데 이렇게 이해하는게 맞을까요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? ( 예 /아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? ( 예 /아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? ( 예 /아니오) [질문 내용] 안녕하세요. 강의 잘 수강하고 있습니다. 다름이 아니라, 순수 자바로 작성된 AppConfig 파일을 스프링으로 전환하는 과정에 궁금한 점이 있어 질문드립니다. 일단 해당 과정에서 AppConfig 내부의 모든 메소드들을 Bean으로 등록하셨는데요. memberRepository나 discountPolicy는 orderService 혹은 memberService의 의존성 주입을 위해 만들어진 메소드들로, 외부에서 사용되지 않을 것으로 보이는데 맞을까요? 따라서 Bean으로 등록할 필요도 없고 public으로 설정할 필요도 없어보이는데, 강의 내에서는 Bean으로 등록하고 public으로 설정한 다른 이유가 있을지 궁금합니다.
