## 📣버그에 대한 설명 및 재현 방법 - `DBInitializer` 사용 시 `AUTO_INCREMENT`에 의한 오류 발생 - 이는 테스트 시 `Fixture`에서 미리 정의해 둔 `ID`를 사용했기 때문에 발생함. - 해당 픽스처에 존재하는 ID는 실제로 DB에 저장되는 테스트가 아닌 `Repository`를 모킹하는 경우, 즉 실제 DB엔 저장하지 않는 경우에만 사용하라고 작성해놓은 것임. (작성할때 의도는 이랬는데 이후에 나도 대충 되겠지 하며 가져다 쓰긴 했다..) - DB의 `AUTO_INCREMENT`는 별도의 카운터를 유지하여 증가함을 보장함. - 이때 카운터 증가는 트랜잭션 단위로 락을 거는 것이 아니라, 뮤텍스를 사용함. - 즉 Tx1에서 `INSERT (ID = 1) -> INSERT (ID = 2)` 이후 커밋하지 않더라도 Tx2에서 `INSERT`를 수행하면 `ID=3`이 된다. 이후 Tx1이 롤백을 하더라도 Tx2는 그대로 `ID=3`인 값이 유지되고 카운터도 그대로 유지된다. - 테스트 환경에선 트랜잭션 롤백을 통해 격리성을 유지하므로, 위의 문제가 발생한다. 여러 테스트를 동시에 수행하면 각 트랜잭션 내에서 첫번째로 `INSERT` 하더라도 `ID=1`임이 보장되지 않는 것임 - 픽스처에서 미리 정의한 ID를 그대로 쓰는 것은 `첫번째로 넣었으니 ID가 1이 겠지?`라는 전제가 들어가므로 에러가 발생하던 것 ## ✨개선 계획 - [ ] `E2ETest` 에선 `DBInitializer`가 아닌 `Repository`를 사용하도록 변경 - 가능하면 `Repository`를 통해 직접 데이터를 입력하는 것이 아닌, 처음부터 각 요청을 보낼 것 - `회원가입-로그인-팔로우-프로필조회`의 형식으로 시나리오 형태가 되어야 된다 생각함 - 이 경우 본인(ex. JOHN)은 위 시나리오 대로 요청을 쭉 보내는 것이 맞으나, 팔로우 대상(ex. ALICE)는 Repository를 통해 미리 저장해놓아도 되지 않을까? - [ ] `RepositoryTest`에선 무조건 `Repository` 사용
