왜 값이 두번 들어가지? 왜 값이 두번 들어가지? #241
-
사전 설명친애하는 백엔드 여러분 안녕하세요 저희는 히스토리의 카테고리를 분류하기 위해 HistoryCategory라는 엔티티를 생성하여 사용하고있습니다. @Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class HistoryCategory extends BaseEntity {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Enumerated(EnumType.STRING)
@NotNull
@Column(name = "history_type", nullable = false)
private HistoryType historyType;
@Builder
private HistoryCategory(HistoryType historyType) {
this.historyType = historyType;
}
}문제상황저 같은 경우 PetPlantService를 테스트하는 과정에서 문제를 발견했습니다. 저희는 ReminderService를 구현하는 과정에서 다음과 같은 코드로 HistoryCategory를 찾아온 뒤 저장하게됩니다. HistoryCategory historyCategory = historyCategoryRepository.findByHistoryType(HistoryType.LAST_WATER_DATE)
.orElseThrow(
() -> new NoSuchElementException("존재하지 않는 히스토리 타입입니다. type: " + HistoryType.LAST_WATER_DATE));해당 코드는 HistoryType은 단 한개만 존재해야한다 (unique) 조건이 선행되어야 무결한 코드입니다.
때문에 HistoryType에 unique조건을 추가했습니다
그러자 테스트에서 다음과 같이 unique 제약조건으로 인한 문제가 터졌습니다. 확인 결과 요약
// 문제의 코드 중 일부
@BeforeEach
void setUp() {
dictionaryPlant = dictionaryPlantSupport.builder().build();
member = memberSupport.builder().build();
for (HistoryType type : HistoryType.values()) {
historyCategorySupport.builder()
.historyType(type)
.build();
}
}따라서 궁금한 점은 왜 2번씩 저장되는가? 입니다 |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 7 replies
-
|
해당 문제에 대한 원인을 파악해서 공유합니다. 원인인수테스트에서 저장된 값이 통합테스트에 흘러들어옴. 인수테스트에서 컨텍스트 영역에 저장된 값이 통합테스트에서 초기화하지 못하여 발생하는 문제로 파악했습니다. 기존 통합테스트의 경우 결국 인수테스트가 다 끝난 뒤에는 데이터가 남아있게 되는 것이죠... 조치 방법이에 다음과 같은 방법을 생각해볼 수 있습니다.
|
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
넵 히스토리 뿐만 아닌 |
Beta Was this translation helpful? Give feedback.
-
|
beforeEach에서 히스토리 카테고리를 생성하는데 반려_식물_삭제시_히스토리도_함께_삭제된다() 테스트에서 history를 생성하는 historySupport 내부에서 카테고리를 또 생성합니다. 이 부분도 고려해야겠네요 !
historySupport
|
Beta Was this translation helpful? Give feedback.
-
저는 첫번째 방법이 좋은 것 같아요. |
Beta Was this translation helpful? Give feedback.
-
|
인수테스트에서 저장된 값이 통합테스트에 흘러들어오는 상황이 모든 테스트에 공통적으로 적용됩니다 ! 그러므로 인수테스트의 BeforeEach/AfterEach에 에 DB 초기화 구문을 작성하는 방법을 선택하는 방안이 좀 더 나아보입니다. 추가적으로, 인수 테스트의 이슈와는 별개로 위 코멘트에서 언급했던 부분도 해결해야할 것 같아요 😀
|
Beta Was this translation helpful? Give feedback.
-
넵 활용 가능합니다!
해당 의견에 대해서는 개인적으로 반대하는 의견입니다!
위 두가지 조건에 의해 테스트 내부에서 해당 도메인 규칙을 계속하여 신경쓰는 부분이 테스트 생산성을 저하할것이라는 생각이 들었습니다. public class HistoryCategorySupport {
private final HistoryCategoryRepository historyCategoryRepository;
public HistoryCategory findByHistoryType(HistoryType type) {
return historyCategoryRepository.findByHistoryType(type).orElseGet(null);
}
...
} |
Beta Was this translation helpful? Give feedback.
-
|
오 좋아요 ~ |
Beta Was this translation helpful? Give feedback.
-
|
저는 2번 인수테스트의 AfterEach에 DB초기화 구문을 작성하면 DB 데이터 초기화를 할 때 불필요한 중복작업이 발생한다는 문제점도 생각해볼 수 있을 것 같아요 |
Beta Was this translation helpful? Give feedback.
-
|
문득 든 생각인데 |
Beta Was this translation helpful? Give feedback.
-
|
AfterAll이면 제가 우려하고있던 문제를 해결할 수 있어보이네요! AfterAll을 사용하는 방향이라면 2번 방법보다 괜찮은 방법이라는 생각이 듭니다 👍 |
Beta Was this translation helpful? Give feedback.
-
|
다만 현재 |
Beta Was this translation helpful? Give feedback.
-
위 2가지로 정리할 수 있겠네요 ! |
Beta Was this translation helpful? Give feedback.
-
|
다음 PR에 해당내용 반영했습니다 |
Beta Was this translation helpful? Give feedback.
AfterAll을 활용해 인수 테스트가 모두 종료되면 데이터베이스를 클리어한다.historyCategorySupport에서 null인 경우 생성하지 않고 조회 로직을 제공한다.위 2가지로 정리할 수 있겠네요 !