[6기] 3주차 Wordle 과제 제출 - 도니 by hyojin23 · Pull Request #41 · woowahan-pjs/java-wordle

hyojin23 · 2026-01-12T17:01:00Z

페어 : 사이몬
방식 : 10분 타이머를 이용, 드라이버와 네비게이터 교체, 40분 or 60분마다 10분 휴식
진행 :
1/5(월) 21:00 ~ 23:00 (2시간) - 온라인
1/9(금) 20:00 ~ 23:00 (2시간) - 오프라인
1/10(토) 15:00 ~ 18:00 (3시간) - 온라인

- task list - 구상도

- trial counter - word input handler

Application 수정

- words.txt 못읽는 이슈 해결 - 승리여부 판단해서 작성

- 소문자로 인풋을 변경합니다.

- 테스트 생성 및 예시 테스트를 생성합니다.

TrailCounterTest 테스트코드 추가 WordComparatorTest 테스트코드 추가

- 정답 입력 문구 추가 FileReader - indent 수정 WordComparator.getPartialMatchedIndex - 부분일치 판단 로직 오류 수정 WordDrawer - 문자 대신 색깔 블록 출력하도록 변경

zinzoddari

안녕하세요 도니님!
도니님의 코드 리뷰어를 담당하게 된 진조링입니다.

저도 초보 리뷰어라 저의 가치관이 잔뜩 묻어있는 부분일 수 있는데요 😅
제가 작성한 내용이 곧 정답이 아니기도 하고,
도니님의 의견도 궁금하기에 작성한 내용이기 때문에
무조건 반영하지 않아도 됩니다.

일단 12가지의 코멘트를 달아보았는데요.
저희 천천히 맞춰가봐요 💪🏻

화이팅!

zinzoddari · 2026-01-26T11:19:30Z

src/main/java/view/FileReader.java

+    public FileReader() {
+    }
+
+    public String read(Path path) {


해당 부분에 path를 파라미터로 선언 하셨지만, 코드 내에서는 전혀 사용이 되지 않고 있더라구요.

혹시 이 부분은 사용이 되지 않는 부분일지, 혹은 개발 과정에서 깜빡하신건지 궁금합니다.

우선 path를 read() 메서드의 파라미터로 선언했지만 사용하지 않은 부분은 개발 과정에서 깜빡한 실수라고 생각됩니다.

그래서 이를 어떻게 수정할까 생각하며 찾아본 결과, Path path 대신 String resourceName을 read() 메서드의 파리미터로 받도록 수정해 보았습니다.

그렇게 한 이유는 words.txt 파일이 src/main/resources/ 경로에 있는데, 이 경로에 있는 파일은 컴파일 후 클래스패스(자바 런타임이 클래스(.class)와 리소스(.txt, .properties)를 찾는 경로)에 복사된다고 합니다.

기존처럼 Path.of()로 경로를 읽을 경우 로컬 파일 시스템 경로 e.g. C:\Users\user\project\src\main\resources\words.txt 라 프로젝트를 빌드해서 jar 파일이 되면 경로를 읽을 수 없지만,
클래스패스는 JVM이 찾을 수 있는 경로라 jar 파일로 변환해도 경로를 읽을 수 있다고 합니다!

따라서 Application에서 Path.of()를 사용해 파일 시스템 경로를 사용하는 것보다, resource 이름(words.txt) 만 파라미터로 주고 FileReader에서 getResourceAsStream() 메서드로 파일을 읽는 것이 jar로 변환해도 안전하게 동작할 수 있는 방식이라 생각되어 그렇게 수정해 봤습니다.

감사합니다!

zinzoddari · 2026-01-26T11:21:13Z

src/main/java/view/FileReader.java

+        }
+    }
+
+    private static Long getTodayWordIndex () {


해당 메서드는 FileReader 클래스 내에서만 참조되는 것으로 보여요.
static으로 선언하신 이유가 있을까요?

말씀해주신 대로 FileReader 클래스에서만 사용하기에 static으로 선언할 필요가 없는 것 같아 static은 제거했습니다. 감사합니다!!

zinzoddari · 2026-01-26T11:23:41Z

src/main/java/view/FileReader.java

+        Long counter = 1L;
+        try (InputStream is = FileReader.class.getClassLoader().getResourceAsStream("words.txt")) {
+            try (BufferedReader br = new BufferedReader(new InputStreamReader(is, StandardCharsets.UTF_8))) {
+                while (!getTodayWordIndex().equals(counter)) {


해당 메서드 내부에 디버깅 한 번 찍어서 구동 해 보시면 좋을 것 같아요.
제가 직접 돌려 봤을 때, 오늘의 단어 index와 counter가 같을 때 까지 매번 연산을 해주는 로직이더라구요.

getTodayWordIndex() 연산은 한 번만 처리하고, 그 결과 값을 가지고 비교를 해보는 방식에 대해서는 어떻게 생각하실까요?

말씀해주신 대로 루프를 돌 때마다 getTodayWordIndex()를 매번 호출하는 대신, 한번만 호출 후 비교하는 게 불필요한 연산

을 줄일 수 있는 것 같아 그러한 방식으로 수정했습니다. 감사합니다!

zinzoddari · 2026-01-26T11:33:46Z

src/main/java/view/FileReader.java

+        }
+    }
+
+    private static Long getTodayWordIndex () {


추가로 메서드 명과 괄호 사이에 띄어쓰기가 조금 신경 쓰이더라구요 🥹

IntelliJ IDE를 쓰신다면, 커밋하기 전에 macOS 기준으로

코드 자동 정렬 (Reformat Code) : Option + Command + L

Import 문 최적화 (Optimize Imports) : Option + Command + O

단축키를 이용해 정리를 해주신다면, 어느정도 일관된 스타일로 유지 가능하실거에요!

이거는 우리 코드 과제뿐만 아니라, 회사에서도 꼭꼭 써야하는 단축키!

감사합니다! 윈도우를 쓰고 있어서 해당 단축키 사용해서 코드 정렬 후 반영했습니다!!

코드 자동 정렬: Ctrl + Alt + L

Import문 최적화: Ctrl + Alt + O

단축키 이용해 코드 정리하는 습관이 아직 안들어서 계속 습관 들이려 노력해야 할 것 같습니다..

zinzoddari · 2026-01-26T11:36:45Z

src/main/java/model/WordComparator.java

+
+public class WordComparator {
+
+    Map<Character, Integer> map = new HashMap<>();


해당 map의 접근 제어자가 defult인 것 같은데, 혹시 이유가 있을까요?

다른 코드를 봐도 해당 부분은 직접 접근은 없어 보이기 때문에, 꼭 잊지 않고 캡슐화를 해 줄 필요가 있어보입니다.

해당 map은 getPartialMatchedIndex()에서만 사용하는 map이고 getPartialMatchedIndex() 호출마다 매번

초기화 되어야 해서 getPartialMatchedIndex() 메서드 내부의 지역변수가 되도록 변경했습니다.

또한 가독성을 고려해 변수명을 map -> todayWordMap으로 변경했습니다. 감사합니다!

zinzoddari · 2026-01-26T12:07:11Z

src/main/java/view/WordDrawer.java

+        } else {
+            System.out.println("You lost: The End");
+        }


else문을 쓰지 않고 풀어본다면 어떻게 풀어볼 수 있을까요?

else문 제거를 위해 if문에서 메시지 출력 후 return 하는 방식으로 수정해 보았습니다. 감사합니다!

public static void showTheEnd(boolean gameOver) { if (gameOver) { System.out.println("You won: The End"); return; } System.out.println("You lost: The End"); }

zinzoddari · 2026-01-27T07:22:49Z

src/main/java/Application.java

+
+public class Application {
+    public static void main(String[] args) throws IOException {
+        // 1) FileReader 오늘의 단어 뽑기


해당 로직들은 main이 아닌, 좀 더 적절한 이름을 가진 객체한테 위임해보는건 어떨까요?
저의 경우에는 GameMachine 이라는 객체를 만들어서, main에서는 게임머신 객체를 이용해 게임을 시작할 수 있게 구성을 해 보았습니다.

프로세스를 실행시키는건 main 메서드의 역할이 될 수 있지만,
게임의 흐름을 main 메서드에서까지 관리하는건 좀 벗어나는 역할이지 않을까 생각이 들었어요!

감사합니다!

WordleGame 이라는 클래스를 추가해 main에서 해당 객체를 통해 게임을 진행할 수 있게 변경했습니다.

관련 커밋: bbedfde

zinzoddari · 2026-01-27T07:26:21Z

src/main/java/view/FileReader.java

+    public FileReader() {
+    }


FileReader 객체에만 기본 생성자가 작성되어 있는데, 혹시 어떠한 의도로 작성되어 있는걸까요?

FileReader에 현재 다른 생성자가 없기 때문에 불필요하다고 판단되어(자바에서 기본 생성자는 만들어주니) 지웠습니다. 감사합니다!

zinzoddari · 2026-01-27T07:37:26Z

src/test/java/model/TrialCounterTest.java

+        trialCounter.increment();
+        assertEquals(trialCounter.getTrials(), 1);
+
+        trialCounter.increment();
+        assertEquals(trialCounter.getTrials(), 2);


개인적으로 저는 하나의 테스트 코드는 하나의 검증만 나와야된다고 생각해요.
지금은 검증하는 부분이 두 곳이게 되는데,

충분히 increment()를 한 번만 호출해도 테스트의 의도가 충분히 전해진다고 생각이 들어요.

to-be

@Test @DisplayName("increment 는 trials가 1 증가한다.") void increment() { // given final TrialCounter trialCounter = new TrialCounter(); final int expected = 1; // when trialCounter.increment(); // then assertEquals(trialCounter.getTrials(), expected); }

저는 이렇게 BDD Given-When-Then 형식으로 테스트 코드를 작성하는 습관을 들이고 있는데요.
이렇게 되면, 불필요한 로직은 없이 꼭 검증해야 되는 부분만 간결하게 코드를 작성할 수 있게 되는 것 같더라구요.

Given : 시나리오 진행에 필요한 값을 설정

When : 시나리오 진행에 필요한 조건 명시

Then : 시나리오 완료 했을 때 결과 명시

감사합니다! BDD Given-When-Then 형식으로 TrialCounter에 관한 테스트 코드를 개선 및 추가해 보았습니다.

@Test @DisplayName("increment를 한 번 호출하면 trials는 1이다") void incrementOnce() { //given final TrialCounter trialCounter = new TrialCounter(); //when trialCounter.increment(); //then assertThat(trialCounter.getTrials()).isEqualTo(1); }

관련 커밋: 2331b0c

zinzoddari · 2026-01-27T07:48:29Z

src/test/java/model/WordComparatorTest.java

+
+class WordComparatorTest {
+
+    @Test


비슷한 관심사끼리 테스트 코드를 묶을 수 있다는 것도 아시나요?
@Nested 어노테이션을 이용해서 처리가 가능합니다.

@Nested를 이용해서 테스트 관심사를 모았을 때의 결과인데요.
훨씬 쉽게 읽히지 않나요?

성향의 차이지만, 테스트 코드는 한 번 작성하고 계속 유지보수를 해주어야하는 코드이기 때문에
테스트 코드의 가독성 역시 저는 중요하다고 생각하기에, 이 부분도 챙긴다면 더욱 좋은 개발 환경이 되지 않을까 싶습니다!

감사합니다! @Nested 어노테이션을 처음 알게 되었는데 테스트 코드 작성 시 적극적으로 사용해 보도록 하겠습니다!

TrialCounterTest 클래스에 @Nested 적용한 결과

관련 커밋: 61bedc6

- Path 대신 String resouceName을 받도록 수정 - getTodayWordIndex() 메서드 호출 한번만 이뤄지도록 수정 - getTodayWordIndex() 메서드 static 제거 및 리턴 타입 long으로 변경 - FileReader 기본 생성자 제거

- getPerfectMatchedIndex() 메서드명 오타 수정 - map -> todayWordMap으로 변수명 변경 - todayWordMap을 지역변수로 설정해 getPartialMatchedIndex() 호출마다 초기화 되도록 수정 - clearMap() 메서드를 만들어 getPartialMatchedIndex()에서 depth 3인 문제 해결

- getPerfectMatchedIndex() 메서드명 오타 수정

- TileColor Enum 추가

- else문 제거 후 if문에서 early return 하도록 수정

- static list 제거 후 WordResult 기반 history 적용 - draw() -> addResult()로 변경 - showPrompt()를 인스턴스 메서드로 수정

- getPartialMatchedIndex()에서 완전일치 인덱스 제외 처리 - 코드 줄 정렬

- 이전 시도 결과가 모두 출력되도록 WordDrawer 인스턴스를 루프 밖에서 생성

- trials 증가, keepTrying 동작, gameOver 상태 테스트 - withTrials static factory 사용으로 테스트 가독성 개선

@nested

- @nested를 사용해 테스트코드를 기능별로 묶음

- WordleGame 클래스에서 게임 진행하도록 수정

- WordComparator 비교 로직을 compare()로 캡슐화

- 기존 테스트 제거 후 compare() 메소드에 대한 테스트로 변경

- 글자 완전 일치를 판단할 수 있는 isPerfect() 메서드 추가

zinzoddari

1차 리뷰는 어느정도 정리된 것 같아요.
도니님 너무 고생 많으셨습니다.

기존 반영 해주셨던 로직 기반으로
그 다음으로 코멘트 남겨봅니다!

조금 더 힘내보아요!!

zinzoddari · 2026-02-04T06:17:16Z

src/main/java/view/FileReader.java

+
+public class FileReader {
+
+    public static final int WORDBOOK_SIZE = 2309;


단어장에 누군가가 단어를 추가하거나 삭제를 하게 되면, 해당 크기는 매번 수정을 해야되는걸까요?

words.txt 파일을 읽고 List로 반환해서 해당 List 사이즈를 사용하도록 변경했습니다. 감사합니다!

관련 커밋: 20cd6b3

zinzoddari · 2026-02-04T06:19:29Z

src/main/java/view/FileReader.java

+            while (counter != todayIndex) {
+                br.readLine();
+                counter++;
+            }


FileReader의 read라는 메서드는, 외부 환경에서 파일을 읽어오는 역할이 핵심이지 않을까 싶어요.
하지만, 지금 코드의 경우

오늘의 단어의 index를 구하기

읽어온 라인이 오늘의 단어 index와 같은지
같은 추가적인 동작을 하고 있지 않나 싶어요.

이럴 때에는 저는 더 적절한 이름을 붙여줄 수 있지 않을까 생각이 드는 것 같습니다.

FileReader 클래스 구조 개선 -> FileReader는 파일을 읽는 행동만 수행하고, WordIndexCalculator와 WordSelector에서 오늘의 단어를 구하도록 변경해 보았습니다.

관련 커밋: 20cd6b3

zinzoddari · 2026-02-04T06:25:52Z

src/main/java/view/FileReader.java

+import java.time.LocalDateTime;
+import java.time.temporal.ChronoUnit;
+
+public class FileReader {


저의 경우에는 이런 FileReader 클래스는 Util 성 역할을 한다고 생각해서
이럴 땐, 상속 조차 못하도록 클래스에 final 키워드를 붙여주는 편입니다.

public final class FileReader { // final 추가 ...

이렇게 될 경우, 다른 클래스에서 FileReader 클래스를 상속 받지 못하게 되는데요.

또한, 별도로 클래스 생성을 하지 못하도록 기본 생성자 역시 private으로 제한을 두는 편입니다.

private FileReader() { }

그러면 자연스럽게 read 메서드도 static 형식이 될 것 같아요.

public static String read(String resourceName) { ...

이런건 스타일의 차이기 때문에 제가 구현 했더라면 이렇게 했을 것 같다~ 하고 한 번 공유드려봅니다.

그러면 호출하는 부분에서는

String todayWord = FileReader.read("./words.txt");

이렇게만 호출할 수 있을 것 같아요.

저도 FileReader는 Util성 클래스라는데 동감합니다!

그래서 말씀해주신대로 클래스에 final 키워드를 붙여 상속하지 못하게 하고, readAllLines() 메서드를 static 메서드로 변경했습니다.

관련 커밋: 20cd6b3

제 리뷰어이신 고도파님이 이야기 주신건데 개인적으로 공감이 또 되어서 도니님께도 공유드려봐요.
저는 리뷰할 때 까지 FileReader는 유틸성이지 않을까 싶었는데,
반대로 파일 읽는 것 뿐만 아니라, 만약 DB나 외부 API로 가져오게 되면 이거는 유틸성이 아닐 수도 있지 않을까 싶더라구요.

일단, 먼 미래 Util 클래스를 만들게 된다면, 저는 class에 final 키워드를 작성하는 편을 선호하기에
이후 참고 해보시면 좋을 것 같습니다.

커밋 내용 봤는데, 확실히 파일 읽기 역할만 하도록 잘 수정이 된 것 같습니다. 👍🏻

zinzoddari · 2026-02-04T06:30:02Z

src/test/java/model/TrialCounterTest.java

+    }
+
+    @Nested
+    @DisplayName("gameOver 관련 테스트")


@Nested를 통해 테스트를 이어줄 때,
한 번 순차적으로 읽어봐보세요.

저는 책 읽듯 한 문장으로 이어지는 것을 선호하는 편인데요.

"gameOver 관련 테스트. gameOver이면 trials가 남아있어도 keepTrying은 false다"
이런 형식보다는

"gameOver 값은, trials가 남아 있더라도 keepyTrying이 false면 false를 반환한다." (이게 맞을까요 ㅎ..)
이런 문장 형식으로 작성하게 되면, 새로운 사람이 도니님 이후에 코드를 작성하게 되더라도
도니님께 질문하지 않고도 테스트 코드를 통해서 비즈니스 이해를 도울 수 있다고 생각해요.

이것도 참고만 해주세요 ㅎㅎ

좋은 것 같습니다. TrialCounterTest에서 테스트 코드 동작 시 좀 더 읽기 쉬운 문장이 되도록 개선해 봤습니다!

관련 커밋: 558d612

zinzoddari · 2026-02-04T06:34:32Z

src/test/java/model/TrialCounterTest.java

+            assertThat(counter.getTrials()).isEqualTo(3);
+        }
+    }
+}


맨 뒤에 EOF 에러가 왜 발생하는지 궁금하지 않으신가요?

🔗 GitHub 파일 끝에 개행이 필요한 이유 (no newline at a end of file)

해당 글 한 번 참고해 보시면 좋을 것 같습니다.

감사합니다 생각지도 못했던 부분인데 덕분에 하나 더 배워갑니다!

Settings > Editor > General > Ensure every saved file ends with a line break 체크 완료

zinzoddari · 2026-02-04T06:42:28Z

src/test/java/model/WordComparatorTest.java

+
+import java.util.List;
+
+import static org.junit.jupiter.api.Assertions.*;


저는 import할 때, * 작성하는 것을 선호하지 않는데요.

과거에 제가 별도로 정리 했던 글이 있는데요.
🔗 77 import 와일드카드 (*)

해당 사유 외로도, 실제 업무에서도 문제가 발생했던 적이 있는데...
정확히 상황이 생각이 안나네요. 😅

결국 명확하게 작성하는게 가장 중요하지 않을까 싶습니다.

참고 한 번 해보세욥!

import문에서 *를 쓰는 게 성능에도 영향을 준다는 걸 처음 알게 되었네요!
*가 꼭 필요한 상황이 아니면 import 할 대상을 명확하게 작성하도록 하겠습니다. 감사합니다!

관련 커밋: fa2b15c

zinzoddari · 2026-02-04T06:49:30Z

src/main/java/model/TrialCounter.java

+    public TrialCounter() {
+    }
+
+    public static TrialCounter withTrials(int trials) {


성향의 차이지만, 저는 파라미터로 받아온 trials가
내부 로직에서 상태가 변경되지 않는다면, final 키워드를 통해
변경이 되어서는 안된다고 명시하는 것을 선호합니다.

public static TrialCounter withTrials(final int trials) { TrialCounter counter = new TrialCounter(); counter.trials = trials; return counter; }

이렇게 작성을 하고, 내부 로직에서 상태를 변경하게 되면

이렇게 컴파일 오류가 발생하는 것을 확인할 수 있게 됩니다.

진짜 변경이 필요한 경우는 final을 제거 하고,
첫 개발자의 개발 의도로는 변경이 불가능함을 알려주는 의사소통 방식이라고 생각이 됩니다.

이것도 참고만 부탁드려요 ㅎㅎ

TrialCounter 클래스의 withTrials() 메서드는 trials가 설정된 객체를 생성하기 위해 만든 정적 팩토리 메서드인데요.
매개변수인 trials가 메서드 내에서 변경되어서는 안되기에, 말씀해주신대로 final을 붙이는 게 더 안전하고 처음 개발한 개발자의 의도를 명확하게 알려주는 좋은 방법인 것 같습니다.
감사합니다!

관련 커밋: db4f63b

- FileReader에서 words.txt 읽고 List로 return만 하도록 수정 - WordIndexCalculator에서 List size를 이용해 오늘의 단어 index를 구하도록 수정 - WordSelector에서 오늘의 단어 index를 이용해 오늘의 단어 구하도록 수정

- todayWord -> answer로 변수명 통일 - clearMap -> removeIfZeroCount로 메서드명 변경하여 가독성 개선 - 정답 글자 갯수 세는 Map 만드는 로직를 createWordCharCountMap() 메서드에서 하도록 변경 - perfect index 체크는 boolean 배열에서 하도록 수정

- maxTrials 입력받아 사용할 수 있게 수정 - boolean gameOver -> solved로 변수명 변경

- 문장 형식으로 읽히도록 개선

- 테스트코드 추가

- 메서드 내부에서 값 변경 불가능하도록 final을 붙임

hyojin23 and others added 15 commits January 7, 2026 21:36

Task 정리

723befa

(doc): 기능 문서를 작성합니다.

70ee8bc

- task list - 구상도

패키지 생성

ce1e8d2

FileReader 기능 생성

0f015bc

feature:WordComparator 기능 생성

c4ef9cf

(feature): trial counter 와 word input handler 를 추가합니다.

fa1bda8

- trial counter - word input handler

(feature): application.main 로직을 생성합니다.

d7de700

(feature): WordDrawer 수정

8d02447

Application 수정

(feature): application.main

792bc9d

- words.txt 못읽는 이슈 해결 - 승리여부 판단해서 작성

(feature): inputHandler

c3d6ac1

- 소문자로 인풋을 변경합니다.

(test): WordComparatorTest, TrialCounterTest

aeb0c15

- 테스트 생성 및 예시 테스트를 생성합니다.

(feature):

a22d553

TrailCounterTest 테스트코드 추가 WordComparatorTest 테스트코드 추가

(feature): Application

326be90

- 정답 입력 문구 추가 FileReader - indent 수정 WordComparator.getPartialMatchedIndex - 부분일치 판단 로직 오류 수정 WordDrawer - 문자 대신 색깔 블록 출력하도록 변경

임시 commit

b107ef2

임시

6271746

zinzoddari suggested changes Jan 27, 2026

View reviewed changes

hyojin23 added 5 commits February 1, 2026 23:31

(refactor): FileReader.read 수정

d49dbdd

- Path 대신 String resouceName을 받도록 수정 - getTodayWordIndex() 메서드 호출 한번만 이뤄지도록 수정 - getTodayWordIndex() 메서드 static 제거 및 리턴 타입 long으로 변경 - FileReader 기본 생성자 제거

(refactor): WordComparatorTest 수정

f77969a

- getPerfectMatchedIndex() 메서드명 오타 수정

(refactor): WordDrawer 타일 색상 관리 부분 수정

30f1f29

- TileColor Enum 추가

(refactor): WordDrawer.showTheEnd else문 제거

9b9be77

- else문 제거 후 if문에서 early return 하도록 수정

hyojin23 force-pushed the feature/requirement-donny branch from add4aa0 to 9b9be77 Compare February 2, 2026 15:40

hyojin23 added 8 commits February 3, 2026 01:33

(refactor): WordDrawer 구조 개선

d412538

- static list 제거 후 WordResult 기반 history 적용 - draw() -> addResult()로 변경 - showPrompt()를 인스턴스 메서드로 수정

(refactor): WordComparator 개선

a4a5039

- getPartialMatchedIndex()에서 완전일치 인덱스 제외 처리 - 코드 줄 정렬

(refactor): Application 개선

08bc523

- 이전 시도 결과가 모두 출력되도록 WordDrawer 인스턴스를 루프 밖에서 생성

(refactor): TrialCounter 동작 테스트 추가

2331b0c

- trials 증가, keepTrying 동작, gameOver 상태 테스트 - withTrials static factory 사용으로 테스트 가독성 개선

(refactor): TrialCounterTest 구조화

61bedc6

- @nested를 사용해 테스트코드를 기능별로 묶음

(refactor): WordleGame 클래스 추가

bbedfde

- WordleGame 클래스에서 게임 진행하도록 수정

(refactor): WordComparator 수정

dfc98c1

- WordComparator 비교 로직을 compare()로 캡슐화

(refactor): WordComparatorTest 수정

fa2b15c

- 기존 테스트 제거 후 compare() 메소드에 대한 테스트로 변경

(refactor): WordResult 수정

e869070

- 글자 완전 일치를 판단할 수 있는 isPerfect() 메서드 추가

zinzoddari suggested changes Feb 4, 2026

View reviewed changes

hyojin23 added 8 commits February 5, 2026 02:46

(refactor): TrialCounter 구조 개선

0f172cb

- maxTrials 입력받아 사용할 수 있게 수정 - boolean gameOver -> solved로 변수명 변경

(refactor): 출력 메시지 영어 -> 한국어로 변경

d6bd911

(refactor): playTurn()에서 게임 시도 횟수 / 총 횟수 출력하도록 수정

cf35463

(refactor): TrialCounterTest @DisplayName 수정

558d612

- 문장 형식으로 읽히도록 개선

(refactor): WordComparatorTest

43d577c

- 테스트코드 추가

(refactor): TrialCounter.withTrials 파라미터에 final 키워드 추가

db4f63b

- 메서드 내부에서 값 변경 불가능하도록 final을 붙임


		public class WordComparator {

		Map<Character, Integer> map = new HashMap<>();


		public class FileReader {

		public static final int WORDBOOK_SIZE = 2309;


		import java.util.List;

		import static org.junit.jupiter.api.Assertions.*;

Conversation

hyojin23 commented Jan 12, 2026

Uh oh!

zinzoddari left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hyojin23 Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zinzoddari left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

hyojin23 Feb 1, 2026 •

edited

Loading

hyojin23 Feb 1, 2026 •

edited

Loading

hyojin23 Feb 1, 2026 •

edited

Loading

hyojin23 Feb 1, 2026 •

edited

Loading

hyojin23 Feb 2, 2026 •

edited

Loading

hyojin23 Feb 4, 2026 •

edited

Loading

hyojin23 Feb 3, 2026 •

edited

Loading

hyojin23 Feb 3, 2026 •

edited

Loading

zinzoddari Feb 4, 2026 •

edited

Loading