목차 1. 자바의 예외 2. checked vs unchecked 3. 예외 처리 전략 자바의 예외 자바에서 예외는 크게 3가지로 나뉜다. Exception - 검사 예외, checked Exception RuntimeException - 비검사 예외, unchecked Exception Error - 에러 이 중 에러는 개발자가 어떻게 처리 할 방법이 없으므로, checked, unchecked 예외를 잘 처리해야한다. (Exception, RuntimeException, Error 전부 아닌 Throwable 객체 - 만들지 말기. 쓸데없고, 햇갈리기만 함.) checked vs unchecked Exception(checked) RuntimeException (unchecked) 처리 여부 반드시 ..
최대한 간단하게 정리하고, 세부 구현은 레포 보기 목차: Test Double + mock vs stub JUnit Assertion AssertJ + 다른것과 비교 Mockito + 다른것과 비교 BDD TDD Test Double Test Double 스턴트맨을 stunt double 이라 한다. 여기서 따온 말이 test double이다. test double은 위험한 일을 대신 해준다. ex) 어떤 service를 테스트 할때, db와 관련된 영향은 배제해야 할 것이다. test double은 실제 db와 관련된 역할을 대신한다. Test Double을 예전에는 만들어 사용해야 했지만, 이제는 Mockito같은 프레임워크들이 기능을 제공하여 편하게 생성할 수 있다. 종류 크게 Dummy, Stub..
테스트를 작성하다가, 코드가 너무 많아져서 내가 어디를 테스트 안했는지 알 필요가 생겼다. Jacoco를 사용하면 테스트 커버리지를 쉽게 알수 있다. instructions: Java bytecode 명령 수 branches: 분기, 조건문 수 ex) 위 사진에서 컨트롤러는 분기가 거의없고 서비스에 요청을 전달만 하니까 저렇게 missed branches가 낮은것. 이렇게 테스트 커버리지를 확인하고, 더 작성해주면 이렇게 커버리지를 증가시킬수 있다. 색깔 초록색: 테스트 완료 노란색: 몇가지 상황중 하나만 테스트 완료 (성공 테스트는 완료 했으나, 실패 테스트는 없을때) 빨간색: 테스트 없음 커버리지 빌드시에 테스트 코드 커버리지가 낮으면 실패하도록 설정 가능하다. 이상적인 테스트 커버리지는 당연히 10..
이 글은 정답이 아닌 개인적인 저의 생각 정리입니다...! . . . 고민 개발을 하다보면 계속 Controller와 Service의 역할에 대한 의문이 들었다. Controller가 Service에 있어야할 비즈니스 로직을 가지고 있게 된다고 생각했기때문이다. (내가 그렇게 했기때문에 그런거지만... ㅠㅠ) 실제로 내가 겪은 구체적인 상황: 어떤 컨트롤러의 post 요청에서 A,B,C 엔티티가 반드시 순서대로 생성된후 저장되어야 한다. (참조관계 때문에 그렇다) 기존에는 컨트롤러에서 A 엔티티 생성 -> AService.createA() 한 후 B, C도 동일한 과정을 거침. 이러니까 컨트롤러가 서비스의 역할을 해버린다고 생각함. 코드: //기존 코드 @PostMapping public Response..
클래스 단위로 @Builder 사용시 필드를 전부 초기화 하지 않으면 예상하지 못한 일이 생길수도 있다. @Entity @Builder public class Book { @Id @GeneratedValue @Column(name = "book_id") private Long id; @Column(name = "book_name") private String name; @Column(name = "book_isbn") private String isbn; @Enumerated(EnumType.STRING) @Column(name = "book_category") private BookCategory category; @OneToMany(mappedBy = "book") private List posts ..
Servlet- 서블릿은 예전에 스프링같은 편리한 프레임워크를 사용하기전 사용했다고한다. 서블릿의 역할 서블릿은 프로그래머가 핵심적인 코드만 작성하도록 도와준다. 의미있는 비즈니스 로직 외에도 저런 수많은 작업을 처리해줘야 한다. 연결하고 파싱하고 연결끊고... 이런걸 전부 한땀한땀 하기에는 너무나도 힘들다. 난 대학에서 네트워크 시간에 http connection을 만들고 파싱하고 이런걸 해봐서 이 고통을 이해한다. 그게 싫었던 사람들은 서블릿을 만들어냈다. 스프링부트는 기본 내장 was로 톰켓을 사용한다. was로 http 요청이 들어오면 was는 response와 request 를 생성하여 서블릿컨테이너에서 싱글톤으로 관리되는 서블릿 객체에 넘겨준다. + 동시요청에 대비해 멀티쓰레딩을 이용해 서블릿..
강의내용 빈 스코프란? -> 빈이존재할 수 있는 범위이다. 우리가 알고있던 빈 존재 범위는 사실 싱글콘 빈의 범위이다. 그게 기본값이니까. 하지만 스프링은 다양한 스코프를 지원한다. 1. 프로토타입 2. 웹관련 -request, session, application 스코프 등등이 존재한다. 프로토타입 스코프 매우 짧은 스코프이다. 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다 -> 그러므로 @PreDestory는 동작하지 않는다. 그리고 싱글톤이 아니니까 이렇게 클라이언트는 서로 다른 빈을 받게된다. 이런 특성을 지닌 프로토타입 빈을 싱글톤과 같이 쓴다면 어떻게 될까? 프로토타입 빈이 호출됐지만, 결국 클라이언트 빈 호출시 한번만 호출되므로, 기대한 결과가 안나오게 된..
강의 복습 스프링에서 DB 연결 같이 초기화랑 종료 작업이 필요한 일을 어떻게 해야할까? 초기화 콜백, 소멸전 콜백 이 두개를 사용하면 된다. 그전에 알아야 할 사실...! 스프링 빈의 이벤트 라이프사이클 스프링 컨테이너 생성 스프링 빈 생성 의존관계 주입 초기화 콜백 사용 소멸전 콜백 스프링 종료 이 순서로 이루어진다. 다시 돌아와서, 다양한 방식으로 이런 생명주기 콜백을 지원한다. 1. 인터페이스(InitializingBean, DisposableBean) 2. 설정 정보에 초기화 메서드, 종료 메서드 지정 3. @PostConstruct, @PreDestory 애노테이션 지원 이 중에서 @PostConstruct, @PreDestory 애노테이션을 사용하자 이유? -> 최신 스프링에서 가장 권장하는..
