AspectJ 에서 어떻게 바이트 코드를 조작하는 지 궁금하다.

• 텍스트에디터 보면, 알수없는 바이트 코드들이 나옴. 사실 명확히 정의되어잇음.
• 고도의 노가다성 작업으로 수정, 변경 가능함. AspectJ 전문가들이 뛰어나 잘 작업함.
• 같은 이름 파일을 바꿔치기도 하고,
• 런타임 위빙도 사용.
  • 클래스를 읽어야 사용 가능한데, 읽는 순간, 로딩된 클러스를 바꿔치기 하는 방법이 있다.
• 자바 API 이용하는 방식. 다 장단점이 있다. 런타임 위빙은 추가작업이 필요하다.

롤백 테스트 시, 기존 비즈니스 로직 속 트랜잭션을 검증할 수 없다는 단점이 있지 않은가?

• 커밋 완료 시 트랜잭션 단위 끝나고 DB 반영 확인…
• 커밋 완료되지 않아도 확인 가능하다!!
• 쿼리 날아가면, 엔티티들이 롤백 된다해도 DB에 쿼리는 전달된다!!
• 플러시 되면, DB에 실제로 반영은 됨. 커밋 완료된 후, 결과 검증이 가능하다. → 플러시 키워드 더 공부하기

JPA 롤백 테스트 주의사항

• JPA의 persistant context 안에서 엔티티를 추가, 세이브할 때 커밋 직전까지 DB에 인서트 쿼리가 안나가다가 나중에 한번에 날아감. 쓰기지연.
• ID 조회 시 데이터를 바로 읽어가게 해서 성능향상도..
• 롤백테스트 시, 인서트 실행 후 조회, 테스트 끝날 시 DB에는 쿼리가 안날아가고 테스트가 끝날지도…
• 매핑에 문제가 있다… 인서트쿼리가 DB에 날아가야 확인이 가능할텐데, JPA 테스트를 롤백으로 만들 시 매핑 문제 상황에서도 테스트가 성공하기도 한다!
• 플러시모드 관련 설명들이 많이 있다. 잘 찾아봐라.
• 테스트 만들 때, DB 모든 작업들이 다 플러시가 되었는지 확인해라. 플러시를 강제로 해라. 그것만 주의하면 된다!!
• 테스트 용 디비를 통해 테스트 전후 데이터 변화를 확인. 트랜잭션 롤백 못시키면 테스트에서 디비 바꾼걸 복귀작업을 테스트 해줘야 함. 번거로움.
• 롤백테스트를 잘 활용해라. DB까지의 동작과정을 잘 알아봐야.