fix: Stage1Test#noneRepeatable 설명 주석 오타 수정

[minSsan]

25.10.10(월) 일자에 개인 DM으로 문의드렸던 내용입니다!

[coderabbitai]

Walkthrough

study/src/test/java/transaction/stage1/Stage1Test.java의 noneRepeatable 테스트 내 주석 문구가 변경되었으며, 사용자 B의 변경이 읽기 전 미커밋 상태에서 커밋된 상태로 서술이 수정되었습니다. 코드 및 로직 변경은 없으며, 공개 또는 내보내는 엔티티의 선언 변경도 없습니다.

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	PR 설명이 개인 DM 언급만 포함하고 있어 변경된 테스트 주석 수정 내용과 아무 관련이 없으며 수신자가 변경사항을 이해할 수 없습니다.	PR 설명을 변경된 Stage1Test.noneRepeatable 주석 오타 수정 내용을 반영하도록 구체적으로 업데이트해 주세요.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	이 제목은 Stage1Test.noneRepeatable 테스트의 주석 오타 수정이라는 주요 변경사항을 간결하게 요약하고 있어 PR의 핵심을 명확히 전달합니다.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

study/src/test/java/transaction/stage1/Stage1Test.java (1)

157-157: 주석 수정 적절합니다. Non-repeatable read 맥락과 일치합니다.

subConnection이 기본 auto-commit이어서 사용자 B의 변경이 커밋된 상태라는 설명과 코드가 일치합니다. 학습 혼동을 줄이기 위해 바로 위 주석에 “subConnection은 auto-commit”임을 명시해보면 어떨까요? 또한 메서드명 noneRepeatable(철자) → nonRepeatable로 정합성도 한번 점검해보실래요?

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 555788a and 6b15524.

📒 Files selected for processing (1)

• study/src/test/java/transaction/stage1/Stage1Test.java (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.java

⚙️ CodeRabbit configuration file

**/*.java: ## 🎯 코드 품질 중심 리뷰 가이드라인

이 리뷰는 코드 품질과 객체지향 원칙에 집중합니다.
미션 달성 여부가 아닌, 코드 설계와 품질 개선에 대한 피드백을 한글로 제공해주세요.

📚 학습 원칙

• 직접 코드를 제공하지 마세요 (학습자가 명시적으로 요청하는 경우 제외)
• 문제 해결 과정을 안내하되, 정답을 바로 알려주지 마세요
• 작은 단계로 문제를 분해하여 접근하도록 도와주세요

💡 피드백 방법

• 유도 질문 활용: "만약 ~라면 어떻게 될까요?", "~를 고려해보셨나요?"
• 힌트 제공: 방향은 제시하되, 구체적인 구현은 학습자가 하도록
• 다양한 접근법 제시: 한 가지 해결책이 아닌 여러 가능성을 제안
• 왜?에 집중: 단순히 무엇이 잘못되었는지보다 왜 그런지 이해하도록

⚡ 객체지향 생활 체조 원칙 검토

다음은 객체지향 생활 체조(Object Calisthenics) 9가지 원칙입니다.
위반 시 학습 효과를 위해 반드시 피드백을 제공하되, 왜 이 원칙이 중요한지 설명해주세요:

규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만

• 들여쓰기 depth 최대 1 (중첩 제어구조 금지)
  • 📖 이유: 메서드 복잡도 감소, 단일 책임 원칙 강화
  • 💡 힌트: "이 부분을 별도 메서드로 추출하면 어떨까요?"

규칙 2: else 예약어 금지

• else, switch/case 사용 금지
  • 📖 이유: 복잡한 분기 제거, 명확한 코드 흐름
  • 💡 힌트: "early return이나 가드 클로즈 패턴을 고려해보세요"

규칙 3: 모든 원시값과 문자열 포장

• 원시 타입과 String을 객체로 포장
  • 📖 이유: 도메인 개념 명확화, 비즈니스 로직 응집
  • 💡 예시: int port → Port port, String name → Name name

규칙 4: 한 줄에 점 하나만 (디미터 법칙)

• 메서드 체이닝 제한
  • 📖 이유: 결합도 감소, 캡슐화 향상
  • 💡 나쁜 예: request.getUri().getPath().substring()
  • 💡 좋은 예: request.extractPath()

규칙 5: 축약 금지

• 명확한 이름 사용 (축약어 금지)
  • 📖 이유: 코드 가독성, 의도 명확화
  • 💡 예시: req → request, calcAmt → calculateAmount

규칙 6: 모든 엔티티를 작게 유지

• 클래스 50줄, 메서드 10줄 이하
  • 📖 이유: 단일 책임, 이해와 테스트 용이성
  • 💡 힌트: "이 클래스가 너무 많은 일을 하고 있지 않나요?"

규칙 7: 인스턴스 변수 3개 이하

• 클래스당 최대 3개의 인스턴스 변수
  • 📖 이유: 높은 응집도, 단일 책임 유지
  • 💡 힌트: "관련 필드들을 별도 객체로 묶을 수 있을까요?"

규칙 8: 일급 컬렉션 사용

• 컬렉션을 감싸는 클래스 사용
  • 📖 이유: 컬렉션 로직 캡슐화, 불변성 보장
  • 💡 예시: List<HttpHeader> → HttpHeaders 클래스

규칙 9: 게터/세터/프로퍼티 금지

• Tell, Don't Ask 원칙 준수
  • 📖 이유: 진정한 캡슐화, 객체 자율성
  • 💡 나쁜 예: if (user.getPassword().equals(input))
  • 💡 좋은 예: if (user.authenticate(input))

🎯 추가 프로그래밍 요구사항

코드 스타일

• Java Style Guide 준수
• 3항 연산자 사용 금지

테스트 및 구조

• **모든 기능 T...

Files:

• study/src/test/java/transaction/stage1/Stage1Test.java