[🚀 사이클2 - 미션 (블랙잭 베팅)] 파도 미션 제출합니다. by choubung · Pull Request #1099 · woowacourse/java-blackjack

choubung · 2026-03-13T02:12:07Z

안녕하세요 웨지!
일단은 사이클2 기능 구현에 집중했어요.
이번 사이클이나 선택미션 때 기회가 되면 말씀해주신 것처럼 DDD스럽게 바꿀까 생각 중입니다...
지금 구조는 좀 아쉬운 것 같아서요.
궁금한 점은 아래와 코멘트에 달아두었습니다! 감사합니다😄

체크 리스트

미션의 필수 요구사항을 모두 구현했나요?
Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

이미 알려주신 경계값 테스트 외에 좋은 테스트를 작성하는 웨지만의 팁이 있는지 궁금합니다. 또, 테스트를 작성하면 어떨 땐 프로덕션 코드보다도 품이 훨씬 많이 드는데, 이게 맞는 건지, 맞다면 어디까지의 품이 적절한 건지 어떻게 판단할 수 있는지 궁금해요.
여러 존재들이 얽혀 있다 보니, 어디까지를 한 도메인으로 나눌지도 고민이 되는 것 같습니다... 이걸 판단할 수 있는 팁이 있을까요?

money 검증 로직 포함

BlackjackService와 BettingTable 변경

기존에 Name에 들어 있던 name string을 꺼내서 반환해왔으나, Name이라는 vo가 존재하는 이유에 반한다고 생각하여 값이 오갈 때 Name에 감싸져 있을 수 있도록 수정함

money의 생성자 추가 블랙잭 여부 판별을 위해 HandCards에 사이즈 반환 메소드 추가

choubung · 2026-03-14T03:39:17Z

src/main/java/domain/BettingTable.java

+    public Money calculateProfit(Player player) {
+        if (player.getWinStatus() == WinStatus.WIN && player.isBlackjack()) {
+            return new Money(bettingTable.get(player).getValueOf() * BLACKJACK_BONUS);
+        }
+
+        if (player.getWinStatus() == WinStatus.LOSS) {
+            return new Money(0);
+        }
+
+        return bettingTable.get(player);
+    }
+
+    public Money getDealerProfit() {
+        return new Money(bettingTable.values()
+                .stream()
+                .mapToInt(money -> money.getValueOf())
+                .sum());
+    }


테스트를 작성하려고 하니, 미리 세팅해야 하는 값들이 많은데(승리 판별),

클래스 분리가 제대로 되지 않아 테스트가 더 힘든 상태인건지, 아니면 베팅이 초기와 마지막에 걸쳐 있는 기능이기에 이것 저것 세팅할 것이 많은 건지 궁금합니다.

또, 깊이가 너무 깊어질 때는 특정 메소드를 호출했을 때 정해진 값을 반환하도록 하는 가짜 객체를 만들어 테스트 해도 되는지, 그 방식이 지금 여기 적용하기에 올바른지도 궁금합니다.

테스트 할 게 많다는 건 if 분기가 많다는 뜻이어요. 분기 하나 하나가 가치있는지 검토하세요.
가치가 있다면, 보호해야 될 비즈니스 로직이 맞으니까 열심히 테스트하시면 됩니다.

객체 분리가 잘 되어있으면 단위테스트를 통해 그런 분기들을 줄여볼 수 있어요.
예컨데 Money에서 1000원 단위 validation을 안 해주고 돈계산 할 때 같이 한다고 하면,
10000원 + 승리조건 / 9999원 + 승리조건 / 10000원 + 패배조건 / 9999원 + 패배조건
이렇게 분기의 개수가 지수적으로 증가하게 됩니다.

이게 단위적으로 잘 분리되어 있으면 분기수가 감수하겠죠.

깊이가 너무 깊어질 때는 특정 메소드를 호출했을 때 정해진 값을 반환하도록 하는 가짜 객체

이게 도메인 단위 테스트가 잘 되어있으면 자연스럽게 줄어들어요. (하위 단위 테스트를 믿고 상위에선 적절한 값을 지닌 객체만 주입)

어쨌든 "특정 메소드를 호출했을 때 정해진 값을 반환하도록 하는 가짜 객체를 만들어 테스트" 필요하다고 생각하시면 구현 후 리뷰주셔요. 보면서 또 말씀드릴게요

넵!! 지금 도메인이 필요한 역할만 들고 있는지, 테스트가 보호해야할 로직을 잘 검증하는지에 집중해서 한 번 테스트를 작성해볼게요!!

choubung · 2026-03-14T03:41:55Z

src/main/java/domain/participant/Participant.java

    }
+
+    public boolean isBlackjack() {
+        return handCards.getHandCardsSize() == 2 && getScore() == BLACKJACK_CONDITION;


매직 넘버를 쓰고 싶지 않았는데요,,,,
'블랙잭인지 아닌지 플레이어가 판단하는 게 맞나? 게다가 해당 상수가 BlackjackService에 이미 정의되어 있는데, 여기서 해야 할 일을 플레이어가 하고 있는 게 아닌가? 그런데 여기서 이 로직으로 밖으로 빼면 다른 곳에서 너무 복잡해지는데 코드 구조가 전반적으로 잘못된 걸까?' 라는 생각이 들어 리뷰를 받고 나서 방향성에 맞게 수정하고 싶어서 일단 두었습니다...

매직넘버를 왜 쓰면 안 되는지 학습해보세요. 파도가 아닌 다른 개발자가 이 코드를 봤을 때, "2가 뭐지?" 고민하게 만들 여지가 있으면 매직넘버입니다.

클래스 상수 간의 의존은 두번째 문제에요. 여러 도메인에 중복 정의 되더라도 가독성에 불편을 주면 매직넘버를 제거하는 게 맞습니다.

저는 실제론 본 메서드처럼 누가봐도 명확한 경우 (손 개수 2개여야되는구나) 상수화 하진 않아요.
대신 의미를 분명하게 하기 위해 handCards.getHandCardsSize() == 2 자체를 메서드화 할거 같아요 (blackjackHandSizeCheck.. 대충 지은 메서드명인데 이런 느낌으로요.)

웨지 코멘트를 보고 조금 찾아봤는데요, 이런 식으로 메소드를 써서 코드를 좀 더 가독성있게 만들 수 있단 걸 처음 알았습니다. 감사합니다!

sihyung92

안녕하세요 파도! 리뷰어 웨지입니다

Q1. 테스트 코드의 적정선
A1. 사이클 1 때 다른 리뷰이의 코멘트에서 테스트의 중요성에 대해 얘기한 게 있는데, 링크 첨부해요. 3번만 보셔요

중요성은 그렇다 치더라도, 거기에 들이는 공수가 고민이신 것 같은데요. 테스트는 ai한테 초안 맡겨보세요. (무조건 accept하지 마시고, 결과에 대해 같이 보면서 학습 효과를 일으켜보세요)

Q2. 도메인을 나누는 기준
A2. 전 응집도를 기준으로 봅니다. "이 데이터와 이 로직이 항상 같이 변경되는가?"를 보세요. 같이 변경된다면 한 도메인, 따로 변경된다면 분리 대상입니다. 응집도나 결합도 같은 개념에 대해서 고민하고 계신걸로 봤어요. 읽어봐도 잘 모르겠는 개념들은 너무 힘들게 접근하지 마시고, 본인이 이해가 가능한 버전으로 천천히 만들어보셔요. (ai한테 이해가 갈 때까지 계속 되물어보세요.) 코드는 결국 내가 납득한 개념들만 녹아들어가고, 이해 못 하고 적용한 패턴은 나중에 리팩토링 대상으로 돌아오거든요.

테스트 짜보시고 다시 요청주세요~

sihyung92 · 2026-03-15T02:18:35Z

src/main/java/domain/vo/Money.java

+
+public class Money {
+    private static final int MIN_INCREMENT = 10_000;
+    private final int money;


돈을 Int로 다루고 계신데요, 돈을 다루는 데 적절한 자료구조를 학습하고 바꿔보셔요.

BigDecimal을 활용하도록 수정하겠습니다!

sihyung92 · 2026-03-15T02:27:14Z

src/main/java/domain/vo/Money.java

+
+    private void validateMinIncrement(int value) {
+        if (value < MIN_INCREMENT || value % MIN_INCREMENT != 0){
+            throw new IllegalArgumentException("[ERROR] " + MIN_INCREMENT+ "원 단위여야 하며, 최소 금액은 " + MIN_INCREMENT + "입니다.");


오류 풍부화 해주세요 (input도 함께 로깅)

보통 서버단의 오류를 화면단까지 출력시키는 경우는 잘 없긴 해서요. 나중에 가면 궁극적으로는 서버개발자를 위한 로그만 남기게 될 텐데요
(모든 오류 종류를 프론트가 정의하는 건 어렵기 때문에 뷰 단을 위한 출력용 메시지를 따로 만들어서 전달합니다.)

본 미션에서 사용자 입장에서 보더라도, 향후 서버개발자 로그 입장에서 보더라도 내용이 풍부한 오류를 정의하는 건 항상 도움되는 일입니다

로그 상세화가 버릇이 안 되어서 자꾸 놓치네요.. 주의하겠습니다!!

sihyung92 · 2026-03-15T02:36:17Z

src/main/java/domain/BettingTable.java

+    public Money calculateProfit(Player player) {
+        if (player.getWinStatus() == WinStatus.WIN && player.isBlackjack()) {
+            return new Money(bettingTable.get(player).getValueOf() * BLACKJACK_BONUS);
+        }
+
+        if (player.getWinStatus() == WinStatus.LOSS) {
+            return new Money(0);
+        }
+
+        return bettingTable.get(player);
+    }
+
+    public Money getDealerProfit() {
+        return new Money(bettingTable.values()
+                .stream()
+                .mapToInt(money -> money.getValueOf())
+                .sum());
+    }


테스트 할 게 많다는 건 if 분기가 많다는 뜻이어요. 분기 하나 하나가 가치있는지 검토하세요.
가치가 있다면, 보호해야 될 비즈니스 로직이 맞으니까 열심히 테스트하시면 됩니다.

객체 분리가 잘 되어있으면 단위테스트를 통해 그런 분기들을 줄여볼 수 있어요.
예컨데 Money에서 1000원 단위 validation을 안 해주고 돈계산 할 때 같이 한다고 하면,
10000원 + 승리조건 / 9999원 + 승리조건 / 10000원 + 패배조건 / 9999원 + 패배조건
이렇게 분기의 개수가 지수적으로 증가하게 됩니다.

이게 단위적으로 잘 분리되어 있으면 분기수가 감수하겠죠.

깊이가 너무 깊어질 때는 특정 메소드를 호출했을 때 정해진 값을 반환하도록 하는 가짜 객체

이게 도메인 단위 테스트가 잘 되어있으면 자연스럽게 줄어들어요. (하위 단위 테스트를 믿고 상위에선 적절한 값을 지닌 객체만 주입)

어쨌든 "특정 메소드를 호출했을 때 정해진 값을 반환하도록 하는 가짜 객체를 만들어 테스트" 필요하다고 생각하시면 구현 후 리뷰주셔요. 보면서 또 말씀드릴게요

sihyung92 · 2026-03-15T02:37:05Z

src/test/java/domain/vo/MoneyTest.java

+    }
+
+    @ParameterizedTest
+    @ValueSource(strings = {"9999", "10001", "0", "-10000", "11000"})


경계값 테스트를 잘 지키고 계시네요. 이런 습관이 커리어에서 장애를 한번 막아주는 갈림목입니다.

감사합니다😄
확실히 경계값이나 분기 값을 잘 테스트 해야한다는 걸 이번 미션을 하며 많이 느꼈어요

sihyung92 · 2026-03-15T02:42:59Z

src/main/java/domain/participant/Participant.java

    }
+
+    public boolean isBlackjack() {
+        return handCards.getHandCardsSize() == 2 && getScore() == BLACKJACK_CONDITION;


매직넘버를 왜 쓰면 안 되는지 학습해보세요. 파도가 아닌 다른 개발자가 이 코드를 봤을 때, "2가 뭐지?" 고민하게 만들 여지가 있으면 매직넘버입니다.

클래스 상수 간의 의존은 두번째 문제에요. 여러 도메인에 중복 정의 되더라도 가독성에 불편을 주면 매직넘버를 제거하는 게 맞습니다.

저는 실제론 본 메서드처럼 누가봐도 명확한 경우 (손 개수 2개여야되는구나) 상수화 하진 않아요.
대신 의미를 분명하게 하기 위해 handCards.getHandCardsSize() == 2 자체를 메서드화 할거 같아요 (blackjackHandSizeCheck.. 대충 지은 메서드명인데 이런 느낌으로요.)

sihyung92 · 2026-03-15T02:49:25Z

src/main/java/domain/participant/Participant.java

구현체로 사용할 일이 없는 객체여서요, abstract로 처리하시면 좋겠네요. 좋은 코드는 용도로만 사용되게 최대한 제약하는 거여서요

넵 수정하겠습니다!!

dto 사용으로 인한 입력값 변경 mockito 삭제 기타 변경

Name으로 Player를 찾는 메소드 추가

choubung · 2026-03-17T10:43:54Z

src/test/java/domain/BettingTableTest.java

+    private final Name playerName = new Name("테스트");
+    private BettingTable bettingTable;


원래 mockito를 사용했었으나, 베팅 계산 메소드에서 dto를 받게 되면서 (기존에는 Name, WinStatus, boolean(isblackjack을 받았었음) 사용할 필요가 없어져 삭제하였습니다!

choubung · 2026-03-17T10:56:41Z

안녕하세요 웨지!

전반적인 리팩토링도 함께 하고, 테스트를 짜며 전반적으로 코드를 점검하다보니 수정할 로직도 몇 있어서 늦어지게 되었습니다....

처음에는 mockito를 사용해서 테스트를 작성했었는데요, 테스트 작성 자체도 불편했지만, 로직 자체도 이것 저것 연결된 게 많아 리팩토링 대상이라고 생각해서 구조를 수정했어요. 기존에 Name, Winstatus, isBlackjack을 매개변수로 받아 베팅 결과를 계산했는데, 여러모로 불필요하게 얽혀 있다고 생각해서(winstatus랑 isBlackjack 다 무언가로부터 구해야 하는 값) dto를 사용해 아예 값을 service에서 한 번에 담아 전달하는 것으로 바꿨어요.

이번 리팩토링을 하면서 응집도에 대해서 좀 고민을 했고, 객체가 서로를 모른다는 게 어떤 의미인지 조금은 알게 된 것 같습니다. 예전에 웨지가 조언해줬던 것처럼 PlayerManager를 삭제하고 Player를 아예 BlackjackGame 아래로 숨겼어요.

늘 날카롭고 따뜻하게 리뷰해주셔서 감사합니다! 짧은 시간인데도 많이 배워가고 있어요.

sihyung92

안녕하세요 파도, 리뷰어 웨지에요.

여러가지 고민하고 반영해주신 흔적이 보이네요. 리팩토링을 요구하는 리뷰를 드렸는데, 한번 반영해보시고 어려움이 있으면 편히 질문주셔요.

sihyung92 · 2026-03-17T11:43:32Z

src/main/java/service/BlackjackService.java


-    public Money getDealerProfit() {
-        return bettingTable.getDealerProfit();
+    public DealerResultDto getDealerResult() {


getDealerResult나 getPlayerResultInfos는 행위가 있는데요,
getter가 가지는 강력한 고정관념 덕분에 행위가 있을 땐 get 외의 다른 동사 사용을 검토해보세요.

getPlayerInfos, getPlayerInfo와 비교해보면 많은 비즈니스 로직이 포함되어 있으니까요.

sihyung92 · 2026-03-17T11:52:20Z

src/main/java/dto/ResultForBettingDto.java

+import domain.vo.Name;
+
+public class ResultForBettingDto {
+    private final Name name;


어디서는 String name으로, 어디서는 Name name으로 dto간 규칙이 다른데요
하나의 방향으로 통일해주셔요 (다른 리뷰를 반영하면 사라질 객체입니다만)

sihyung92 · 2026-03-17T11:57:11Z

src/main/java/domain/BettingTable.java

+        bettingTable.put(name, money);
+    }
+
+    public Money calculateProfit(ResultForBettingDto dto) {


서로 다른 레이어를 건너갈 때 DataTransferObject, DTO를 쓰는데요
예를들어 도메인 <-> 뷰, 도메인 <-> DB 등 서로 다른 레이어나 아주 먼 사이의 도메인끼리 쓰는 규칙이에요

service 레이어 안쪽 정도는 도메인 끼리의 공간으로 봐서 굳이 dto로 변환해 받을 필요는 없을 것 같네요. 원형 그대로의 Player, Dealer를 받아 처리하도록 해보셔요.

sihyung92 · 2026-03-17T11:59:06Z

src/main/java/domain/BettingTable.java

+
+public class BettingTable {
+    private static final double BLACKJACK_BONUS = 1.5;
+    private final Map<Name, Money> bettingTable = new HashMap<>();


Player 객체에서 eqauls&hashcode를 구현하고, "Name"을 기준으로 하게 하면 Player를 키로 데이터를 뽑을 수 있겠죠

sihyung92 · 2026-03-17T12:10:08Z

src/main/java/controller/GameController.java

-        for (Player player : playerManager.getPlayers()) {
-            blackjackService.dealPlayerCardsOut(player);
+    private void askBettingMoney() {
+        for (Name name : names) {


Player라는 객체 대신 Name인 vo가 다양한 객체와 관계 맺는 건 어색해서요,
Player로 다시 로직을 전개하게 리팩토링 해보시죠.

Player의 속을 보여줄수록 Player의 행위를 수정할 때 따로 고쳐야 하는 부분이 많아집니다. 캡슐화가 주는 가치죠
필요한 곳에서만 getName을 해서 제한적으로 Name을 알 수 있게 해주셔요.

그리고 기존 로직과 현재 로직에 있는, 컨트롤러가 playerManager 혹은 names를 필드로 들고 있는 대신에 이미 해당 데이터를 가지고 있는 BlackjackService로부터 유저 목록을 받아오시죠. (정확히는 BlackjackGame이죠)

sihyung92 · 2026-03-17T12:12:12Z

src/main/java/controller/GameController.java

+import java.util.stream.Collectors;

 public class GameController {
    private final BlackjackService blackjackService;


저는 BlackjackService가 해야하는 역할을 controller가 하고 있기 때문에, (어딘가 "절차" 가 필요할 때 순서를 지정하는 역할) 아예 Service는 제거하고 BlackjackGame과 BettingTable을 직접 의존하여 객체간은 협력만 했으면 어떨까 합니다.
view 형식에 강하게 의존받는 (input을 받으려면 wait 해야됨) 현재 미션에선 서비스 코드가 의미를 가지기 힘들어서요

sihyung92 · 2026-03-17T12:13:05Z

build.gradle

+    testImplementation('org.mockito:mockito-core:5.5.0')
+    testImplementation('org.mockito:mockito-junit-jupiter:5.5.0')


미사용하게 된 의존성은 제거해주세요!

sihyung92 · 2026-03-17T12:41:25Z

src/test/java/domain/BettingTableTest.java

+
+import static org.assertj.core.api.Assertions.assertThat;
+
+class BettingTableTest {


아하, BettingTableTest에서 card, player, dealer의 stub을 모두 만들어야 테스트 할 수 있어서 어려움을 느끼셨군요. stub 만드는 게 항상 고역이고 학습 단위의 미션보다 훨씬 많은 필드를 다루는 현업은 특히 더 그렇습니다.

리뷰 반영하면서 연습한다 치고 한번 해보셔요. 테스트 코드를 만드는 것도 프로덕션과 비슷합니다. 반복되는 요소는 메서드로 추출하고, 가독성 좋게 작성하다 보면 생각보다 아주 힘들지도 않습니다

요번 리뷰요청 주실 때 응집도는 그대로면서, 결합도는 높아졌어요.
BettingTable이 하는 역할 자체는 달라진 게 없으나, Player와 Dealer의 Name, WinStatus라는 상세 구현을 직접 파라미터로 받아 처리해야만 했으니까요

"테스트하기 편한 코드", "테스트가 용이한 코드"를 만들라고 하는 건 "힘이 덜 드는", "짜기 쉬운", "금방 짤 수 있는" 테스트를 만들라는 말이 아니에요.

단위 수준의 테스트를 구현할 수 있고, 로직이 가지고 있는 각 분기에 대한 테스트를 놓치지 않고 할 수 있는 테스트를 만들라는 뜻이어요.

예를들어 "GameController의 메서드 하나에서 모든 코드를 구현하시오"라는 요구사항이었으면, 해당 메서드가 제공하는 모든 기능을 테스트하는 게 불가능하다 싶을 정도 였을거에요.

테스트 코드는 개발자 구동 테스트의 자동화에요. 이 테스트 코드가 없으면 매번 서버를 빌드하고, input으로 여러가지를 입력해봐야 해요. 미션 단위에선 잘 되던 기능 하나가 실패해도 아무 일 없지만, 현업에서는 고객에게 금전으로 보상해야하는 큰 일 일수도 있어요. 그리고 항상 장애는 "새로 구현한 부분"에서 나지 않고 "예상치 못한 사이드이펙트로 인한 기존 기능의 실패"로 나더라구요. 매번 기존에 되던 경우를 확인해주는 게 테스트이니, 당장 구현단계에서 테스트 짜는 게 어려워도 향후 1년 300번의 서버 빌드와 구동 할 시간을 아낀다는 개념으로 보고 공을 들여보셔요.

service 레이어 삭제 내부 비즈니스 로직에서 dto 대신 Player나 Dealer를 직접 참조하도록 변경

choubung added 12 commits March 13, 2026 09:38

Test(Money): Money 검증 테스트 작성

8dc6e0d

Test(Money): money 객체의 integer 값을 받아오는 함수추가로 변경

1680ce9

Feat(Money): money value object 작성

9b6dd2e

money 검증 로직 포함

Feat(view): InputView에 베팅 금액 입력 메소드 추가

e03c568

Feat(view): ResultView에 최종 수익 출력 메소드 추가

db4d88d

Feat: 수익 계산 로직 추가

e325a08

BlackjackService와 BettingTable 변경

Feat(Participant): 블랙잭 판별 메소드 추가

d43da0c

Refactor: 원시값으로 이름 보내지 않도록 수정

da54a68

기존에 Name에 들어 있던 name string을 꺼내서 반환해왔으나, Name이라는 vo가 존재하는 이유에 반한다고 생각하여 값이 오갈 때 Name에 감싸져 있을 수 있도록 수정함

Refactor: 사소한 리팩터링

a0e2397

money의 생성자 추가 블랙잭 여부 판별을 위해 HandCards에 사이즈 반환 메소드 추가

Feat: 베팅 기능 추가

bee3122

Feat(Player): 승패 계산에 블랙잭인 경우도 고려하도록 추가

14e6d8f

Refactor(BettingTable): 사용하지 않는 메소드 삭제

8d3232a

choubung commented Mar 14, 2026

View reviewed changes

sihyung92 requested changes Mar 15, 2026

View reviewed changes

choubung added 2 commits March 16, 2026 12:29

Fix(BettingTable): 승패에 따른 판돈 계산 로직 수정

df11c83

Refactor(Money): int 대신 BigDecimal을 사용하도록 변경

91a11a6

choubung changed the title ~~[🚀 사이클2 - 미션 (블랙잭 게임 실행)] 파도 미션 제출합니다.~~ [🚀 사이클2 - 미션 (블랙잭 베팅)] 파도 미션 제출합니다. Mar 16, 2026

choubung added 13 commits March 16, 2026 12:39

Refactor(Money): 오류 로그가 사용자 입력값도 출력하도록 수정

a5a76a8

Refactor(Participant): 해당 클래스를 추상 클래스로 변경

ba4a1de

Test(BettingTable): 테스트 작성

d8a143f

Refactor: bettingTable 원본 베팅 데이터를 건드리지 않도록 수정

dfad9b5

Build: Mockito 의존성 추가

1486349

Test: 리팩터링으로 인한 변경

959d646

dto 사용으로 인한 입력값 변경 mockito 삭제 기타 변경

Feat(Name): hashCode와 equals 재정의

0b480e7

Refactor: 클래스 삭제 Player를 BlackjackGame 도메인에 숨김

17237df

Refactor(bettingTable): 매개변수를 dto로 변경

c01dd0d

Refactor(Player): 승패 결과를 저장하는 대신 반환하도록 변경

24671de

Feat(PlayerGroup): findByName 메소드 추가

8382ee9

Name으로 Player를 찾는 메소드 추가

Refactor(dto): 기본 정보 dto와 결과 dto를 분리

3b4cc92

Refactor: dto 변경으로 인한 리팩터링

be765ab

choubung commented Mar 17, 2026

View reviewed changes

Refactor(Participant): 매직 넘버를 메소드로 추상화하여 제거

52372d4

sihyung92 requested changes Mar 17, 2026

View reviewed changes

Refactor: 전반적인 리팩토링

9bbd2b8

service 레이어 삭제 내부 비즈니스 로직에서 dto 대신 Player나 Dealer를 직접 참조하도록 변경

		private final Name playerName = new Name("테스트");
		private BettingTable bettingTable;

		testImplementation('org.mockito:mockito-core:5.5.0')
		testImplementation('org.mockito:mockito-junit-jupiter:5.5.0')


		import static org.assertj.core.api.Assertions.assertThat;

		class BettingTableTest {

Conversation

choubung commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

체크 리스트

어떤 부분에 집중하여 리뷰해야 할까요?

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!

sihyung92 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

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!

choubung commented Mar 17, 2026

Uh oh!

sihyung92 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

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

choubung commented Mar 13, 2026 •

edited

Loading