😡 JPA에서 같은 엔티티를 비교할 때 assertEquals()가 실패하는 이유와 해결방법(@Transactional, @EqualsAndHashCode)

🚨 Error :

@SpringBootTest
@Slf4j
public class PostgreDbTest {

    @Autowired
    PostgreRepository postgreRepository;

    @Test
    public void save() throws Exception {

        // 테스트 인스턴스 생성
        Address address = new Address("서울시", "강남대로", "12345");
        Map<String, Object> additionalInfo = new HashMap<>();
        additionalInfo.put("주급", 1000);
        additionalInfo.put("팀", "PSG");
        Member member = new Member( "이강인", 20, "010-1234-5678", "독서", address, additionalInfo);
		
        // Member 엔티티 생성 및 저장
        Member savedMember = postgreRepository.save(member);
        
        // 검증
        Assertions.assertEquals(member, postgreRepository.findById(savedMember.getId()).orElse(null));
    }
}

• postgreSQL 데이터베이스 사용을 익히기 위해 자바 프로젝트를 생성하고 간단하게 테스트를 만들었는데

 

expected: <test.excelparser.postgre.entity.Member@79735611> but was: <test.excelparser.postgre.entity.Member@73476e2d>
Expected :test.excelparser.postgre.entity.Member@79735611
Actual   :test.excelparser.postgre.entity.Member@73476e2d

• 객체의 메모리 상 주소가 서로 다르다고 나왔다.

 

간단히 정리하면

member 객체를 만들고
JPARepository의 save() 메서드를 사용하여 데이터베이스에 저장한 후
곧장 findById로 데이터베이스에 해당 값을 꺼내와서 두 객체가 동일한 지를 비교하는 테스트이다.

단순히 생각해서 객체를 저장하고 그대로 꺼내서 비교하는데 왜 참조하는 주소가 다른지 이해가 가지 않았다.

🤓 원인 :

 

 끝내 퇴근까지 해결하지 못하고 오랜만에 부트캠프 동기들과 만났다. 그렇게 술을 마시다가 에러 생각이 나서 동기들에게 얘기했는데 메인 프로젝트 같이 했던 팀장님이 save() 메서드가 작동한 후 트랜잭션이 끝이 나서 데이터베이스에서 가져온 객체의 주소값이 달라진 것 아니냐는 말씀을 하셨다. 집에 와서 하나의 트랜잭션에서 동작시키기 위해 @Transactional 애너테이션을 사용하니 테스트가 통과되었다. 관련 내용을 GPT에 물어보고 얻은 답변을 정리해 보았다.

 

 

• @Transactional 애너테이션을 사용하면 트랜잭션 범위 내에서 JPA가 영속성 컨텍스트에 저장한 엔티티를 관리하게 된다.
• JPA에서 같은 엔티티를 구분하는 방법은 엔티티의 @Id 필드 값을 비교하는 것이다.
• 그러나, 이 @Id 값은 DB에서 생성된 값이다.
• JPA가 엔티티를 영속성 컨텍스트에 저장할 때는 이 값이 없어서 객체 주소(참조값)를 기준으로 엔티티를 구분한다.
• @Transactional 애너테이션을 사용하지 않으면 JPA가 영속성 컨텍스트에 저장한 엔티티는 해당 트랜잭션 범위를 벗어나는 순간 영속성 컨텍스트에서 분리된다.
  • 참고로, 트랜잭션이 끝나면 commit 되고 flush가 자동 호출되는데 이때 영속성 컨텍스트와 분리되는 것이지 비워지는 건 아니다.
• 이후 findById() 메서드를 호출할 때 새로운 트랜잭션이 시작되어 리턴되는 객체는 주소값이 달라지게 된다.
  
  • 이전 트랜잭션 범위에서 저장한 엔티티가 영속성 컨텍스트에서 관리되었다가 새로운 트랜잭션에서 findById() 메서드를 호출하면, 새로운 트랜잭션 범위로 인해 새로운 영속성 컨텍스트를 사용하게 된다.
  • 새로운 트랜잭션이 시작되어서 새로운 영속성 컨텍스트를 사용할 때는 이전 영속성 컨텍스트에서 관리하던 엔티티의 상태를 초기화한다. 때문에 새 트랜잭션에서는 findById() 메서드를 호출하면 새로운 영속성 컨텍스트에서 이 엔티티의 식별자에 해당하는 엔티티가 없다고 판단하고 데이터베이스에서 다시 조회하게 된다.(findById()에 해당하는 Select 쿼리가 나간다.)
  • 데이터베이스에서 조회한 엔티티 객체는 새로 생성되어 영속성 컨텍스트에 추가된다.
  • 이 때문에 이전 트랜잭션에서 save()한 객체와 다른 주소값을 가지게 되는 것이다.
• 이 상태에서 엔티티를 비교하니 객체 주소(참조값)가 서로 다르기 때문에 `assertEquals()` 메서드가 실패하게 되는 것이다.
• 반대로 @Transactional 애너테이션을 사용하면 JPA가 트랜잭션 범위 내에서 엔티티를 관리하기 때문에 같은 엔티티를 비교할 때 객체의 주소값이 동일하게 된다.
• 즉, 같은 엔티티를 다룰 때 객체 주소가 일정하게 유지되기 때문에 `assertEquals()` 메서드가 예상한 대로 작동하게 되는 것이다.
  • 동일한 트랜잭션 내에서는 영속성 컨텍스트에서 객체를 찾기 때문에 Select 쿼리가 나가지 않는다.

 

🚒 해결 :

방법은 두 가지가 있다.

첫 번째

@SpringBootTest
@Slf4j
@Transactional
public class PostgreDbTest {

	...
}

• @Transactional 애너테이션을 붙여 테스트 로직 전체를 하나의 트랜잭션 범위 안으로 두어 같은 엔티티를 비교할 때 동일한 주소값이 되도록 한다.

 

두 번째

• @EqualsAndHashCode 애너테이션을 Member 클래스에 붙인다.

 

@EqualsAndHashCode

• Lombok(롬복) 라이브러리의 어노테이션이다.
• 이 어노테이션을 클래스에 붙이면 롬복이 자동으로 해당 클래스에 대한 equals()와 hashCode() 메서드를 구현한다.
• 따라서 객체의 동일성 비교가 내부 속성값을 기반으로 수행된다. 
• 예를 들어 아래와 같은 Member 클래스가 있다고 가정해 보면

 

import lombok.EqualsAndHashCode;

@EqualsAndHashCode
public class Member {
    private String name;
    private int age;
    // 기타 멤버 변수 등...
}

• 위와 같이 Member 클래스에 @EqualsAndHashCode 어노테이션을 선언하면

 

public class Member {
    private String name;
    private int age;
    // 기타 멤버 변수 등...

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Member member = (Member) o;
        return age == member.age &&
                Objects.equals(name, member.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

• 컴파일 시 아래와 같이 equals()와 hashCode() 메서드가 자동으로 생성된다.
• 이렇게 되면 객체 간 비교 시 주소값이 아닌 내부 속성값을 비교하여 두 객체의 동일성을 판단하게 된다.
• 이를 통해 영속성 컨텍스트에서 객체를 조회할 때 발생하는 주소값 차이 문제를 해결할 수 있다.

 

🤔 의문점 :

없음!

 

 

 

참고

뤼튼