실무를 하다보면, 개발기간내 시간에 쫒겨 비지니스 로직 구현만 하고, 테스트 코드 작성은 미뤄두다 결국 못하는 경우가 많습니다. 강사님 강의를 듣다보면 로직 구현 이상으로 테스트 코드 작성에 시간을 할애해야 할 정도로 중요하게 얘기를 하시는걸 느낄수 있는데요. 꼭 테스트 코드를 작성해야 하는 이유를 뭐라고 생각해야 할까요? 사실, 그동안은 테스트 코드는 형식상 작성하는거다라고 우선순위를 낮춰 생각해왔거든요. 제가 잘못생각하고 있었다면 조언 부탁드립니다.

수업 내용에 대한 질문은 아닙니다.^^ 다이어그램이 간단해보여 업무 정리로 좋을꺼 같에요. 어느 툴 사용하셨는지 여쭤봅니다.

updateItem 메소드에서 Book이 DB에 저장된적이 있어서 식별자가 존재하여 영속성 컨텍스트에서 관리하지 않는다고 하셨는데요. 1. 그러면 Book을 new Book()으로 생성하고 setId에서 임의로 현재 DB에 존재하지 않는 id를 입력하면 어떻게 될까요?? 2. 준영속 엔티티가 된 이유가 id가 존재해서 라기 보다는 Book 객체의 생성시 영속성컨텍스트를 거치지 않고 생성자를 거쳤기 때문에 준영속 엔티티가 된건 아닌가요??

안녕하세요!강의 정말정말 잘 듣고있습니다! 예제에서는 모두 MemberRepository의 인터페이스를 통해 의존성 주입을 받도록 되어있는데, 그렇다면 스프링 데이터 JPA에서 제공하는 여러 기능들을 이용하기 위해서는 memberRepository에 사용할 기능을 추가해야 하는 건가요~?  새해복 많이받으세요!    

@Configuration 에노테이션 없이 싱글톤이 보장되지 않는다는 것을 테스트코드로 확인하기 위해서 테스트코드 작성을 하였습니다. 그런데 테스트코드를 실행하니 @Configuration이 없음에도, Singleton으로 생성한다는 문구가 보이고, 테스트코드 또한 실패하였습니다. 무엇이 원인인지 잘모르겠습니다..

안녕하세요 강사님, 질문 있습니다. 다형성만으로는 OCP, DIP를 위배할 수밖에 없다고 설명하시며 그에 대한 대책으로 스프링이 나온 것이라고 말씀해주셨는데요. 아마 이는 이전 강의에서 진행하셨던 @Configuration, @Bean을 통한 스프링 컨테이너에 객체를 등록하는 방식을 말씀하는 것일 거라고 생각합니다. 다만 의문점이 드는 부분은.. "스프링을 개발한 개발자들 또한 OCP, DIP 위배 문제에 대한 고민을 하였고 그 해답으로 스프링 프레임워크를 만들었다." 라고 함은.. 스프링이 등장하기 전에도 SOLID라는 개념은 존재했다는 것이겠지요? 그런데 OCP, DIP 위반 문제를 해결하기 위해 스프링을 만들었다? 그렇다면 스프링이 등장하기 전에는 어떤 방식으로도 SOLID를 모두 충족시킬 수 없었다는 말인가요? 그렇다면 저 SOLID라는 개념을 처음 제시했을 사람은.. 문제에 대한 해결책도 없이 그냥 객체지향 설계의 이상향만 제시했을 뿐인 건가요?  알쏭달쏭 하네요; 이번 강의도 잘 듣겠습니다. 감사합니다! ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 바로 다음 강의에서 스프링 등장 이전 배경에 대한 설명이 다시 간략하게 나오네요. 스프링이 없이 OCP, DIP를 지켜가며 개발을 하다보니 배보다 배꼽이 커지는 일이 발생했고 그래서 스프링을 만들었다구요. 이로써 첫 질문에 대한 답은 해결이 되었는데.. 음.. 저 스프링 없이 SOLID를 유지하는 코딩 방식에 대한 건 너무 지엽적인 부분이겠죠??ㅠㅠ

안녕하세요!JPA를 활용하여 여러가지 조회테스트를 해보고 있는데 @lob 컬럼이 존재하는 경우 select시 쿼리가 매우 느린현상을 발견했습니다. @lob 컬럼이 존재하는 경우에 쿼리를 빠르게 수행할 수 있는 방법이 있을까요?

안녕하세요 팀장님  프로그래밍 강의를 재미있게 듣기는 처음입니다. ^^ findAllWithMemberDelivery()과 달리 findOrderDtos()에서는 fetch join을 사용하면 에러가 발생합니다.         return em.createQuery(                 "select new jpabook.jpashop.api.dto.OrderSimpleQueryDto(o.id, m.name, o.orderDate, o.status, d.address) " +                         " from Order o" +                         " join  o.member m " +                         " join o.delivery d ", OrderSimpleQueryDto.class         ).getResultList(); <자바 ORM 표준 JPA 프로그래밍>에서는  SELECT m FROM Member m JOIN FETCH m.team 은 다음 SQL문과 같고 SELECT M.*, T.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID=T.ID 일반 JOIN인 경우 SELECT m FROM Member m JOIN m.team t 다음 SQL과 같다 하셨는데 SELECT M.* FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID=T.ID 위에서는 join만 사용했는데 어떻게 member나 delivery를 별도 query로 참조하지 않고 가져왔는지 궁금합니다. 답변하신 내용중 https://www.inflearn.com/questions/23847를 참고하면 "fetch join을 사용하는 이유는 엔티티 상태에서 엔티티 그래프를 참조하기 위해서 사용하는 것입니다. 따라서 당연히 엔티티가 아닌 DTO 상태로 조회하는 것은 불가능합니다. 이 경우 fetch join을 사용하지 마시고, 그냥 순수한 join을 사용하시면 원하는 결과를 얻을 수 있습니다" 라 하셨는데 만약 위의 jpql에 fetch가 있었다면 엔티티 상태이기 때문에 에러가 나지 않고 추후 new를 통해 DTO로 변환해야 하는 것 아닌지요?

start.spring.io에서 프로젝트 생성해서 오픈했는데 바로 오류가 떠서 이것저것 확인해보고 에러메시지 검색해봤는데 잘 못찾겠네요 ㅜ 어떤게 문제일까요??.. 

몇 버전부터 인지는 모르겠으나 2.4.1버전 기준으로는, <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-actuator-autoconfigure</artifactId> </dependency> spring-boot-actuator 의존성 뿐만 아니라 spring-boot-actuator-autoconfigure 의존성을 추가하시고 따라하시면 됩니다. 

ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);해당 코드를 통해서 TestBean 클래스가 컨테이너에 빈으로 등록이 되었으나,TestBean 클래스 내부의 @Autowired 어노테이션의 warning을 살펴보니 **Autowired members must be defined in valid Spring bean** 라는 경고 문구를 볼 수 있었습니다.해당 내용은, 자동의존주입을 받기 위해서는 현재 클래스 또한 스프링 빈으로 등록되어 있어야 한다는 의미로 해석했습니다. 결론은, 이러한 경고가 뜨는 이유를 잘 모르겠습니다.ide가 이 시점에 경고를 잡아주지 못하는 것인가요? 한가지 더 질문을 드리자면,TestBean 클래스에 @Configuration 애노테이션을 붙이게 되면, @Autowiredpublic void setNoBean2(@Nullable Member noBean2) { System.out.println("noBean2 = " + noBean2);}해당 코드에서 noBean2 부분에 빨간 밑줄이 생깁니다. (Could not autowire. No beans of 'Member' type found.)Member 타입의 빈을 찾을 수 없기 때문에 자동주입을 할 수 없다는 의미인데, 당연히 Member는 빈이 아니지만 왜 @Configuration 애노테이션을 붙였을 때 빨간 밑줄이 뜨는지 이유가 궁금합니다. @Autowiredpublic void setNoBean1(Member noBean1) { System.out.println("noBean1 = " + noBean1);}해당 코드 역시 @Configuration 애노테이션이 붙었을 때 noBean1에 빨간 밑줄이 뜹니다.

주문 수량이 재고를 넘어섰을 때,현재는 Error가 발생해서 whitelabel ErrorPage가 뜨는데요, 이 대신  MemberForm처럼 BindingResult를 걸어 hasError() -> 폼에 message를 표시해주는 것과 같은 기능을 넣고 싶은데, 혹시 어떻게 할 수 있을 지 힌트를 주실 수 있으실까요..?

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 위 부분에서 AnnotationConfigApplicationContext 구현체 타입을 사용한 이유가 있을까요? 보니까 AnnotationConfigApplicationContext 타입에서만 getBeanDefinition 메서드를 사용할 수 있더라구요 그러면 AnnotationConfigApplicationContext이 ApplicationContext이 구현체인데 왜 getBeanDefinition을 못하는지가 궁금합니다. (하지만, ApplicationContext에서는 여러 구현체 중에 AnnotationConfigApplicationContext 있는것은 확인했으나 AnnotationConfigApplicationContext클래스에서는 ApplicationContext가 아닌 AnnotationConfigRegistry 구현체로 서로 다르게 명시 되어 있는 것도 궁금합니다. - 구현체는 하나의 인터페이스(하나의 부모)로만 구현한다고 알고 있습니다.)   

안녕하세요 기선님 좋은 강의 감사합니다 :)  스피링 코어 모듈을 개발할 때, Commons Logging 을 사용하고 있었기 때문에, 현재까지도 Commons Logging 이 남아있다고 하셨는데 스프링 5 버전을 만들 때 JCL이란 모듈을 만들어 가며 Commons Logging 코드를 컴파일 타임에 Slf4j 로 바꾸는 이유가 궁금합니다. 짧은 생각으로는 그냥 commons logging 을 빼버리고 slf4j 를 넣었으면 되지 않았나 싶은데 .. 내부적으로 스프링코어의 코드가 commons logging 과 깊게 얽혀있어서 그것보다 JCL을 만드는게 더 비용이 적어서 였을까요?? 

안녕하세요, 강의 듣다 궁금증이 생겨 질문 남깁니다. 질문 1. domain == vo, repository == dao 이렇게 똑같이 봐도 괜찮은 건가요? 같은 것이라면 왜 vo, dao가 아닌 다른 이름을 사용한 것인지, 다른 것이라면 (vo, dao)와 (domain, repository)의 차이점에 대해서도 알려주시면 감사하겠습니다. 질문2. 강의자료에 나오는 Memberservice, MemberRepository, MemoryMemberRepository들의 클래스 의존관계 그림은.. 이번 예제의 상황을 고려하여 만들어진 그림인가요? 아니면 실제 업무에서도 저런식으로 구성된다고 보면 되나요? + 어떤 디비를 사용할지 모르기 때문에 인터페이스로 만들었다는 말이 잘 이해가 안 되는데.. 디비접근방식을 탑재하지 않은 인터페이스를 만들어놓고 사용할 디비에 따라서 implements해서 사용하겠다..는 말이 맞나요?

static inner class로 TestBean을 사용했는데요. static 키워드를 빼면 예외가 발생합니다. 내용을 보니 TestBean.class를 인자로 받아 스프링 컨테이너를 생성하고 인자로 받은 클래스를 빈으로 등록(생성)하는 과정에서 문제가 생기는 걸로 보입니다. 이 상황을 TestBean을 생성하려면 외부클래스(AutowiredTest)의 인스턴스가 필요한데 컨테이너에서 관리하는 정보에 없어서(AutowiredTest가 빈으로 등록되지 않아서) 외부클래스의 인스턴스를 생성할 수가 없고 그로 인해 static이 아닌 내부클래스를 생성(빈으로 등록)하지 못해 발생한 예외라 이해하면 될까요..? static이 붙었을 때는 TestBean을 컨테이너에 등록( 내부적으로 생성자 호출)할 때 외부클래스의 인스턴스 유무는 상관이 없기 때문에 문제없이 동작한다고 이해했고요. 몇 강 전부터 궁금했는데 이제야 질문드립니다. 제가 이해한 내용이 맞을까요? 혹시 잘못 이해한 부분이 있는지 궁금합니다^^ 강의는 정말 재미있게 잘 보고있습니다! 감사합니다^^*

스프링 입문 스프링 데이터 JPA 강의에서  Spring Data JPA에서 제공하는 Repository를 구현하고 있으면 Spring Data JPA가 자동으로 구현체를 등록 해준다. 이 말씀을 하셨었는데 AppConfig가 생성자 주입으로 전달하듯이  Spring Data JPA가 Repository를 구현하고 있는 인터페이스들을 찾아서 주입 역할을 해주고 있는건가요?? @Autowiredpublic SpringConfig(MemberRepository memberRepository){ this.memberRepository = memberRepository;}@Beanpublic MemberService memberService(){ return new MemberService(memberRepository);} 여기에서 SpringDataJpaMemberRepository를 어떻게 찾아가는지 궁금해서 질문 드립니다. (강의 보면서 SI 다니며 묵힌 갈증이 확 풀리는 것 같네요. 강의 감사히 듣고 있습니다. HTTP강의 까지 꼭 완강 하겠습니다!)

안녕하세요 강사님 강의를 보다가 tdd라는 명령어로 테스트 메서드를 생성하는 방법이 궁금해서 관련 가이드를 만들어 보았습니다. https://blog.naver.com/nateen7248/222184184776 혹시 궁금하신 분은 참고해 보시면 될 것 같아요 감사합니다.

안녕하세요. 추천해주신 야생형 스타일에 따라 활용 1편부터 듣고 있는 수강 중인 학생입니다. 매번 강의 너무 잘 듣고 있습니다. 제가 스프링에 대한 이해도가 아직 낮기도 하고, 다른 강의를 이어서 듣다보면 해결될 문제일진 모르겠지만, 이해가 잘 안되는 부분이 자꾸 생각나서 질문 남깁니다. @GetMapping("/test1") @ResponseBody public String test1() { log.info("test1 controller"); try { Thread.sleep(5000); } catch(Exception e) { } log.info("test1 controller finished"); return "test1 finished"; } @GetMapping("/test2") @ResponseBody public String test2() { log.info("test2 controller"); try { Thread.sleep(5000); } catch(Exception e) { } log.info("test2 controller finished"); return "test2 finished"; } 위와 같은 컨트롤러 메서드 코드가 있다고 가정할 때, 각 컨트롤러 메서드가 다른 메서드라면, 각각의 메서드 별로 스레드를  가진 채 실행한다고 이해가 되었습니다. 즉, test1이 실행하는 도중에 test2가 실행될 수는 있지만, test1이 실행하는 도중에 test1은 중복해서 실행될 수 없는 것처럼 보였습니다. 일단 스프링의 작동 방식은 이처럼 이해되었습니다. 그런데 만약 아래와 같이 test1과 test2에서, 동일한 Item객체를 JPA에서 동시에 꺼내온 상황에 업데이트가 일어나면 어떻게 되는지 궁금합니다. 아래의 실행 과정은 제가 개인적으로 생각해본 과정인데, 어떠한 부분이 잘못되었는지 지적해주시면 감사하겠습니다. 1. test1에서 서비스 로직을 실행하는 도중 JPA를 이용하여 Item 객체를 findOne해서 꺼내온다(동시에 영속성 컨텍스트에 등록이 된다는 것처럼 이해되었습니다.) 2. test1가 아직 실행되고 있는 와중에, test2에서 서비스 로직을 실행하는 도중 JPA를 이용하여 Item객체를 findOne해서 꺼내온다(이 객체 또한 영속성 컨텍스트에 등록이 된다는 것처럼 이해되었습니다.) 3. 현재 test1과 test2에서 각각 동일한 Item 객체를 가져와서 영속성 컨텍스트에 등록이 된 상황이라고 보겠습니다. 앞으로 실행 될 test1의 서비스에서는 count를 10올릴 것이고, test2에서는 count를 10내린다고 가정해보겠습니다. 현재 Item 객체에는 100이라는 값이 저장되어있습니다. 4. test1에서 item.addCount(10)을 하면, count는 110이 될 것입니다. 바로 이어서 test2에서 item.removeCount(10)을 하면, count는 90이 될 것입니다. 5. test1의 서비스 로직이 끝나면, @Transactional 어노테이션을 통해 commit이 일어나고, dirty checking을 하며 item 객체의 count를 110으로 업데이트하는 쿼리문을 날릴 것입니다. 6. test2의 서비스 로직이 끝나면, @Transactional 어노테이션을 통해 commit이 일어나고, dirty checking을 하며 item 객체의 count를 90으로 업데이트하는 쿼리문을 날릴 것입니다. 7. 따라서 최종적으로 item 객체의 count값은 90으로 업데이트 될 것입니다. 하지만 실제로는 test1에서 10을 더하고, test2에서 10을 차감하였으니, 동일한 item 객체에 대한 count값은 DBMS 상에서 100으로 유지되어야 맞을 것입니다. 제가 생각한 실행 과정은 90으로 값이 업데이트되며 DBMS의 값의 일관성을 깨뜨리는 상황입니다(물론 제가 짧은 생각대로 실행한 과정의 결과가 90이란 것이지, 코드의 실행 결과가 90이라고 단언한 것은 아닙니다. 결과도 궁금하지만, 100이라는 결과가 나오는 과정에서 어떻게 실행되는지가 궁금한 것입니다!). 어떠한 부분이 잘못되었고, 그 부분은 어떻게 해결되어지는 것인지 궁금합니다. 개인적으로 생각해본 가정은 다음과 같습니다. 가정1 : 동일한 레코드를 조회한 객체에 대해서는 영속성 컨텍스트에 동일한 객체로 기억되기때문에 test1과 test2에서는 동일한 참조 값을 가진 item 객체를 가지고 있다. 따라서 addCount를 할 때 110으로 바뀌고, removeCount를 할 때 100으로 다시 바뀌기 때문에, test1과 test2의 커밋 각각에서는 count 값을 100으로 바꾸는 동일한 update문이 두 번 일어난다. 가정 2 : 동일한 레코드에 대해서 이미 commit 또는 업데이트 된 내역이 있으면, 지금 일어나는 commit은 그냥 ROLLBACK을 시켜버린다. 하지만 이렇게 할 경우, 자바 코드 상에서 DBMS에 저장된 아이템에 대해 동일한 것을 접근했는지 어떻게 기억할 것이며, rollback으로 인한 오버헤드는 감수하는 것인지 의문점이 남습니다. 가정 3 : 동일한 레코드로 조회된 객체에 대해서는 업데이트가 일어나는 전 과정에, 해당 객체에 lock을 걸어둔다. 그러면, 업데이트가 끝나서 commit이 되고, lock을 해제할 때까지 해당 객체에는 접근하지 못한다. 처음에는 이러한 과정이 @Transactional 어노테이션이 붙어있으면, 이 어노테이션이 달려있는 메서드 중에 1개씩만 실행되면서 수행되는 줄 알았는데 제가 아직 개념이 부족한 탓인지 딱히 그렇게 실행되는 것 같지는 않았습니다. 가정 4 : 애초에 이러한 설계가 잘못된 것이다. test1과 test2에서 동시에 item 객체를 수정하는 과정의 코드는 없어야한다. test1 또는 test2, 둘 중에 하나의 메서드에서만 item 객체를 수정할 수 있어야한다. 가정 5 : 그냥 DBMS에서의 트랜잭션처럼 관리된다. 자바 상에서 동시에 실행되는것처럼 보여도 JPA를 통해 serializable한 실행 결과를 보장해준다. 일단 DBMS에서 트랜잭션 간에 동시성을 관리하는 체계를 생각하면, 위와 같은 가정들이 나온다고 생각했습니다. 하지만 그건 DBMS에서의 동시성 관리 체계이지, JPA 상에서도 @Transactional 어노테이션 하나로 그것처럼 동일하게 관리되는지는 잘 모르겠어서 의문이 남습니다. 질문이 미흡해서 제가 의문점을 제대로 남긴 것인지 모르겠네요. 바쁘신 와중에 시간 내 주셔서 감사합니다. +++ @Test@Transactional@Rollback(false)public void 동시업데이트() { // given Book book = new Book(); book.setName("희재의 책"); book.setIsbn("1234"); book.setStockQuantity(100); book.setPrice(30000); em.persist(book); Book book1 = em.find(Book.class, 1L); Book book2 = em.find(Book.class, 1L); // when book1.addStock(10); book2.removeStock(20); Book book3 = em.find(Book.class, 1L); // then assertThat(book1).isSameAs(book2); assertThat(book2).isSameAs(book3); assertThat(book3.getStockQuantity()).isEqualTo(90);} 일단 위와 같은 테스트 코드로 DBMS 상에서 같은 레코드를 조회한 아이템에 대해서는 동일한 객체를 반환하는 것을 확인했습니다. (같은 트랜잭션 상에서만?) 그런데 처음 적은 예시처럼 영속성 컨텍스트에 등록된 동일한 객체에 대해 동시에 커밋이 여러 개 일어나면 어떻게 되는지, 또 이것을 확인해보고 검증하는 테스트 코드는 어떤 식으로 작성해야하는지 잘 모르겠네요.. ㅠㅠ

안녕하세요 영한님, 항상 좋은 강의 감사드립니다. 수업을 듣던 중 의문점이 생겨서 질문 드립니다. 결국 스프링을 사용하는 목적은 애플리케이션 개발에 필요한 기본 뼈대가 되는 기능들은 제공해 줄테니 개발자들은 비즈니스 로직에 집중하여 생산성을 높이는데 집중하자는 것이 목적이라는 생각이 드는데요. 혹시,  예를들어, 파이썬의 장고나 nodejs는 사용목적이 생산성을 높이기 위해 사용하는 프레임워크가 아닌건가요? 만약, 다른 프레임워크들도 결국 생산성을 높여준다는 것이 목적이라면, 다른 프레임워크들과 비교해서 자바의 스프링이 차별성을 갖는 점은 무엇이길래 메이저 it 기업에서 그토록 많이 사용되는 것인지 궁금합니다.