@InjectMocks 는 구현체여야 하는데, 구현체 타입으로 명시하고 싶지 않은 경우 @InjectMocks 를 사용하기 위해서는 구현체 타입이어야 한다. 생각해보면 당연하다. 해당 객체가 갖는 의존성들을 모킹해서 주입해주겠다는 것인데, 실제 구현 객체가 누구인지, 그리고 그 객체가 어떤 이들에 대해 의존성을 갖고 있는지도 모르고 어떻게 모킹해서 주입을 해 주겠는가. 당연한 거지만 이로인해 약간의 고민이 생겼어서 기록해 보았다. 아래와 같은 계층 구조 일 때, JoinAccountService 라는 “회원가입 책임” 을 가진 서비스를 테스트 하고 싶었다. 이 때 JoinAccountService 는 인터페이스로, AccountService 에서는 해당 인터페이스를 구현하는 구현체로서 두었다. 테스트 대..

상황 프론트에서 현재 504 타임아웃 서버 에러가 뜬다는 연락을 받았다 (후에 이 상황의 원인은 vercel 의 서버와 백엔드 서버의 지역이 달라서 생기는 타임아웃 문제 였던 것으로 밝혀졌다) 따라서 프론트에서 문제가 생겼다고 말한 api 를 호출해 보는데 로그에서 이상한 것을 발견했다. 18:10:17.702 [http-nio-8080-exec-9][LoginUserId-1] INFO c.d.c.g.l.a.ControllerLoggingAspect - params : {controller=StudyApi, http_method=GET, method=getDetailInfo, params={}, log_time=Wed Sep 07 18:10:17 KST 2022, request_uri=/api/studi..

Spring 에서는 @Transactional 이라는 어노테이션을 통해 트랜잭션을 쉽게 사용할 수 있다. 스프링에서는 이를 사용하는 방식을 “선언적 트랜잭션을 사용한다" 라고 표현한다. 내부적으로는 AOP 를 사용하여 구현된다. 이미 다들 알겠지만.. AOP 는 “cross-cutting-concern” 즉, 어플리케이션 전반에 걸친 공통적인 관심사 (대표적으로, 커넥션을 가져오고 커넥션을 반환하여 트랜잭션 설정 하는 것 ) 를 비즈니스 로직 으로 부터 분리 시켜 줄 수 있다. 스프링에서 AOP 는 “메소드 레벨 단위로만 적용 가능" 하다는 특징이 있다. 여기서 @Transactional 역시 메소드 레벨로 적용되는 AOP 로 구현되어있다 보니 생기는 문제점은 트랜잭션의 범위를 좁게 유지할 수 없다. 는..

기존의 코드는 위와 같았는데,users 에는 Page 타입의 객체가 담겨져 있었다 count 쿼리에 대한 비용이 불필요하다고 생각해(하지만 1,2,3,.. 의 페이지 번호를 보이는 거라면 어쩔 수 없다 or 프론트에서 단 한번만 총 개수를 받아두고 이를 저장해두고 출력해주는 방법도 있을 수도..??) Slice 로 변경하며 Slice users 가 되었고, 위의 코드를 그대로 사용하면 템플릿 파싱 오류가 발생하는 상황이 되었다. 따라서 Slice 객체를 사용하도록 변경해야 했다. 해당 코드는, 이전 페이지가 존재하는지 여부에 따라 Previous 버튼을 비활성화 시키는 코드다. 따라서 Slice 의 hasPrevious() 를 사용해야 했다. 그런데 users 가 null 인 경우도 존재하기 때문에 아래..

로그인을 구현하지 않았기 때문에 게시글을 작성하는 작성자에 대한 writerId 를 전달 받아와야만 한다. writerId 를 받아와 게시글을 작성하는 서비스 메소드 뿐만 아니라, 후에 로그인 구현을 할 것을 생각하고 ( 이게 잘못되었던 걸까..) Writer 를 인자로 받는 메소드 또한 정의해 놓았다. 컨트롤러에서부터 Authentication 이라던가 Authmember 라던가 LoginMember 라던가 User 객체를 받아올 것으로 생각 했다. 그래서 이 메소드를 내부적으로 호출하도록 하였는데 여기서 @Transactional 과 this…() 에 대한 지적을 받았다 @Transactional public PostDto.PostInfo store(String title, User writer, S..