처음에 service layer에서 프로젝트 생성 시 3개의 파트를 db에 저장하고, 프로젝트 제안자는 자기 포지션에 따라 적절한 파트에 들어가도록 UserPart 테이블에도 데이터가 저장되게 했다.
ProjectRepository를 테스트하면서 project entity 안에 이 로직(프로젝트 생성 시 파트 3개 생성, userpart 1개 생성)이 들어가면 범용성이 좋아질거 같다고 생각했다. 그래서 ProjectService에 있던 로직을 제거하고 ProjectRepositoy에 넣어봤다.
참고로 생성자에는 @Transactional 애노테이션을 쓸 수 없다.
@Target({ElementType.TYPE, ElementType.METHOD})
@Transactional의 타겟에 class는 없다.
그래서 @Transactional을 적용한 메소드를 만든 뒤 생성자에서 호출해줬다. 문제는 다른 클래스의 테스트 케이스에서 발견됐다. 분석해본 결과 Repository layer로 옮긴 로직이 제대로 롤백이 되지 않았다.
검색을 해보았더니 @Transactional은 스프링에 의해 관리되므로 스프링에 의해 관리되는 빈에 선언해줘야 한다. Entity는 hibernate가 관리하는 빈이기 때문에 @Transactional이 적용되지 않는다.
@Transactional을 안 써도 테스트 시 rollback에 문제가 있었다.
@Transactional은 repository나 service layer에서 써야 한다. service layer가 더 추천된다.
'프로젝트 > 크루트' 카테고리의 다른 글
jpa의 orphanRemoval이 잘 작동하는 지 테스트가 하고 싶을 때 (0) | 2022.04.01 |
---|---|
service layer에서는 도대체 뭘 테스트 해야해요? (1) | 2022.03.31 |
모바일 브라우저에서는 로그인이 안 되는 이유 (0) | 2022.03.25 |
https와 cross domain으로 서버와 통신 시 쿠키 보내는 법 (0) | 2022.03.24 |
테스트 케이스를 private으로 작성하면 test를 못 읽어요 (0) | 2022.03.20 |