가짜 DB는 테스트를 통과하지만 실제 DB는 경쟁에서 실패합니다. 두 구현에 공유할 계약 테스트는 무엇인가요?

꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →

잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?

답변과 점검 포인트 펼치기답변 접기

구두 답변

정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.

저장소의 원자 생성·중복 결과·version 충돌·rollback·미존재·권한 오류를 같은 시나리오로 검사합니다. fake의 단일 스레드 동작이 실제 DB보다 강한 보장을 주지 않게 해야 합니다.

빠른 fake 테스트는 정책 분기, 실제 DB 테스트는 잠금·고유 제약·격리·네트워크 실패를 맡깁니다. 결과만 아니라 외부 효과·처리 기록을 확인합니다. 인터페이스가 exists와 insert를 나눠 경쟁을 강요하면 조건부 생성의 의미로 다시 설계합니다.

이해가 드러나는 지점을 확인해 보세요.

저장소의 원자 생성·중복 결과·version 충돌·rollback·미존재·권한 오류를 같은 시나리오로 검사합니다. fake의 단일 스레드 동작이 실제 DB보다 강한 보장을 주지 않게 해야 합니다.
인터페이스가 exists와 insert를 나눠 경쟁을 강요하면 조건부 생성의 의미로 다시 설계합니다.

놓치기 쉬운 조건과 오해를 짚어 보세요.

다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: 저장소의 원자 생성·중복 결과·version 충돌·rollback·미존재·권한 오류를 같은 시나리오로 검사합니다.

하나 더 질문하며 이해의 범위를 넓혀 보세요.

득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.