Api: 🐛 N+1 문제 개선 테스트의 간헐적 실패문제 수정

[asn6878]

작업 이유

CI 환경에서 SpendingSearchServiceTest.java의 간헐적 테스트 실패가 확인되어 이슈 체크 및 수정의 필요성 대두.

작업 사항

에러 발생 원인

원인은 일단 외래키 제약조건의 위반이었습니다.

Spending 객체가 SpendingCustomCategory 테이블에 존재하지 않는 id를 spending_custom_category필드의 값으로 가지게 되면서 위반되었던 것이었습니다.

문제 되는 부분

코드를 다 때려 넣어서 설명하다가 너무 복잡해서 간단하게 줄였습니다.

• SpendingSearchServiceTest.java에서 테스트를 위해 커스텀 카테고리를 가지는 Spending 객체들을 bulkInsert하는 과정이 존재하는데, 이를 수행하기 위해서는 먼저 커스텀 카테고리들을 DB에 생성해 주어야 함.
• 이 때문에 SpendingCustomCategoryFixture 에서 커스텀 카테고리를 capacity 개 만큼 DB에 bulkInsert 함.
• 그 후, capacity 만큼의 Spending들을 DB에 저장함. 이때 CustomCategory 필드에 들어갈 id(외래키) 값은 {1~capacity}사이에서 랜덤으로 뽑았음. 1 + FLOOR(RAND() * %d)

1~capacity 사이의 값들에서 랜덤으로 뽑는 과정이 무엇인가 잘못 된 것 같은데, 제가 직접 찍어본 결과 잘못될 수가 없습니다...
분명히 capacity 개의 커스텀 카테고리들이 저장되고, Spending 객체들을 생성할때는 1~capacity 사이의 id를 사용하는데 여기서 없는 id를 참조할 일이 없는데 말이죠.. (아마 이건 저번에 언급한 병렬실행과 무엇인가 관련이 있는 것 같습니다..)

결국 그래서 저는 기존 코드의 문제점을 찾지 못했습니다....만!
일단은 전에 @psychology50 님이 한번 언급해주셨던 것 처럼 랜덤이 필요없는 곳에 굳이 랜덤을 넣은것이 화근이라고 생각해
fetch테스트의 목적성을 유지함과 동시에 랜덤으로 customCategoryId를 넣어주는 부분을 변경해 외래키 제약조건이 위반될 여지를 완전히 제거했습니다.

그에따라 bulkInsertSpending메소드 사용하는 방법이 변경되었고, 이는 javaDoc으로 명시해 두었습니다.

리뷰어가 중점적으로 확인해야 하는 부분

SpendingFixture.java에서 bulkInsertSpending 메소드만 봐주시면 됩니다.

일단 이것도 가장 크게 의심되는 부분을 제거한 것일 뿐이지, 로컬에서는 실패하는일 없이 계속 성공해서 병합 후 지켜 보아야 할 듯 합니다.... 😢

#119 PR은 본 PR merge이후에 merge하겠습니다~~

발견한 이슈

X

[psychology50]

저도 이런 현상이 발생하는 명확한 이유는 모르지만, 비슷한 경험을 한 적은 있습니다.
아무래도 병렬로 작업들을 수행하면서 pk가 예상치 못한 지점부터 시작한다던가, 여러가지 문제가 있는 거 같아요...^^

여튼 테스트할 때 랜덤값을 넣는 건 서로 주의하는 게 좋을 거 같습니다.