작성
·
179
1
저는 데이터를 새로 생성해서 테스트를 했는데, save와 finditems 두 군데 모두 오류가 발생합니다.
링크 :: https://drive.google.com/file/d/1i7i95iRprKTD08l5TuPj1iCOAVPDvNTT/view?usp=sharing
save 오류 :: org.opentest4j.AssertionFailedError:
expected: hello.itemservicedb.domain.Item@a2df0d5
but was: hello.itemservicedb.domain.Item@26d028f7
finditems 오류 :: org.opentest4j.AssertionFailedError:
Expecting actual:
[hello.itemservicedb.domain.Item@4cc26df,
hello.itemservicedb.domain.Item@7848321e,
hello.itemservicedb.domain.Item@f4f843f,
hello.itemservicedb.domain.Item@7b5833ee,
hello.itemservicedb.domain.Item@1e471884,
hello.itemservicedb.domain.Item@27261190,
hello.itemservicedb.domain.Item@543b0737]
to contain exactly (and in same order):
[hello.itemservicedb.domain.Item@6e46891d,
hello.itemservicedb.domain.Item@48632f69,
hello.itemservicedb.domain.Item@5fde1d64]
but some elements were not found:
[hello.itemservicedb.domain.Item@6e46891d,
hello.itemservicedb.domain.Item@48632f69,
hello.itemservicedb.domain.Item@5fde1d64]
and others were not expected:
[hello.itemservicedb.domain.Item@4cc26df,
hello.itemservicedb.domain.Item@7848321e,
hello.itemservicedb.domain.Item@f4f843f,
hello.itemservicedb.domain.Item@7b5833ee,
hello.itemservicedb.domain.Item@1e471884,
hello.itemservicedb.domain.Item@27261190,
hello.itemservicedb.domain.Item@543b0737]
답변 1
1
안녕하세요. jfk6725님, 공식 서포터즈 OMG입니다.
Item 클래스의 @Getter @Setter를 지우고 @Data로 변경해서 확인해보시겠어요?
롬복의 @Data는 @Getter, @Setter, @RequiredArgsConstructor, @ToString, @EqualsAndHashCode, @Value가 포함되어 있는데요.
이 중 @EqualsAndHashCode로 인한 equals의 재정의가 발생하였고 결과적으로 테스트에 까지 영향이 미치게되었습니다.
아래에서 자세히 설명드릴게요
.
재정의로 인한 영향은 테스트에서 객체 비교 시 isEqualTo()의 동작에도 영향이 발생하였습니다.
assertJ의 isEqualTo는 객체 비교시 객체의 equals()가 재정의되어있지 않을 경우, 때 모든 클래스의 조상인 Object클래스의 equals()를 호출하여 객체간의 참조를 비교하지만
equals가 재정의 됨에 따라 참조값 비교가 아닌 @EqualsAndHashCode가 생성한 equals()가 동작하게 됩니다.
.
save와 finditems 인스턴스도 참조값만 다를뿐 인스턴스가 가지는 값들은 모두 동일한 상황이였으며(@ToString 혹은 @Data로 확인 가능)
@EqualsAndHashCode가 생성해내는 equals()가 어떻게 정의되어있는지는
인텔리제이 기능을 통해 코드를 살펴볼 수 있는데 그 방법은 다음과 같습니다.
예제) @EqualsAndHasdhCode가 적용된 클래스
마우스 우클릭 -> Refactor -> Delombok -> @EqualsAndHashCode선택
@EqualsAndHashCode 구현 코드 확인
이와 같은 절차로 확인 가능하며, Junit 테스트의 assertJ.isEqualTo()가 실행되면 재정의된 equals를 호출하게 됩니다.
참조값만 비교하던 Object클래스의 equals와는 달리
.
Object클래스의 equals()
자기 자신과 같은지를 비교한다거나 (25번째 줄)
if (o == this) return true;
Item클래스의 각 필드값 비교(31번째 줄~40번째줄) 하는 등의 비교 동작이 달리 동작하는 것을 볼 수 있습니다.
그리고 마지막으로 assertJ의 isEqualTo()를 호출하면 이렇게 재정의 된 equals()를 호출하는지 검증하는 방법은
Getter, Setter를 다시 추가한 다음
equals()에 중단점을 추가한 후 (28번째 줄)
테스트를 디버깅 모드로 실행하면 됩니다.
디버깅 모드로 테스트를 실행하면 아래와 같이 equalsAndHash코드가 생성한 equals()가 호출되는 것을 볼 수 있습니다.
감사합니다.
@Data 보다는 @Getter @Setter를 쓰는게 좋다고 하셔서
@Getter @Setter를 쓰고 별도 생성자도 만들었는데,
@Getter @Setter를 @Data로 변경해서 오류가 발생하지 않는 이유가 궁금하네요?