[우테코 5기] 체스 게임 구현 미션 회고

제나랑 함께한 네 번째 페어 프로그래밍이다.

미션을 진행할 당시에는 난이도가 확 뛴 느낌이라 어렵다는 생각, 그리고 시간이 너무 촉박하다는 생각뿐이었는데 다 끝나고 나서 돌아보니까 나름대로 잘 해낸 것 같다. (물론... 코드가 마음에 든다는 말은 아니다 🥹 정말 많이 부족하다...)

그래도 레벨 1 마지막 미션까지 어떻게든 온 내 자신이 대견하다! 앞으로도 힘내자 💪

✔️ 작성한 코드

GitHub - Cl8D/java-chess: 체스 게임 구현을 위한 저장소

✔️ 1차 PR

[1, 2단계 - 체스] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #485 · woowacourse/java-chess

✔️ 2차 PR

[3, 4 단계 - 체스] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #604 · woowacourse/java-chess

✔️ 기능 요구사항

[1단계]

콘솔 UI에서 체스 게임을 할 수 있는 기능을 구현한다.
1단계는 체스 게임을 할 수 있는 체스판을 초기화한다.
체스판에서 말의 위치 값은 가로 위치는 왼쪽부터 a ~ h이고, 세로는 아래부터 위로 1 ~ 8로 구현한다.

체스판에서 각 진영은 검은색(대문자)과 흰색(소문자) 편으로 구분한다.

 

[2단계]

체스 말의 이동 규칙을 찾아보고 체스 말이 이동할 수 있도록 구현한다.
move source위치 target위치을 실행해 이동한다.
체스판의 위치 값은 가로 위치는 왼쪽부터 a ~ h이고, 세로는 아래부터 위로 1 ~ 8로 구현한다

 

[3단계]

체스 게임은 상대편 King이 잡히는 경우 게임에서 진다. King이 잡혔을 때 게임을 종료해야 한다.
체스 게임은 현재 남아 있는 말에 대한 점수를 구할 수 있어야 한다.
"status" 명령을 입력하면 각 진영의 점수를 출력하고 어느 진영이 이겼는지 결과를 볼 수 있어야 한다.

 

- 점수 계산 규칙-

체스 프로그램에서 현재까지 남아 있는 말에 따라 점수를 계산할 수 있어야 한다.
각 말의 점수는 queen은 9점, rook은 5점, bishop은 3점, knight는 2.5점이다.
pawn의 기본 점수는 1점이다. 하지만 같은 세로줄에 같은 색의 폰이 있는 경우 1점이 아닌 0.5점을 준다.
king은 잡히는 경우 경기가 끝나기 때문에 점수가 없다.
한 번에 한 쪽의 점수만을 계산해야 한다.

 

[4단계]

애플리케이션을 재시작하더라도 이전에 하던 체스 게임을 다시 시작할 수 있어야 한다.
DB를 적용할 때 도메인 객체의 변경을 최소화해야한다.

---

미션을 진행하면서 인상 깊었던 부분에 대해 작성해보고자 한다 🫠

 

💬 도메인과 뷰의 의존을 어느 정도로 끊어야 하는가?

사실 자동차 미션 때 도메인이 뷰를 의존해서는 안 되는 이유에 대해 고민했기 때문에, 당연하게도 도메인은 뷰를 알면 안 된다고 생각했다. 하지만, 뷰 역시 도메인을 아는 것에 대해서는 고려하지 않았다. 어차피 뷰는 도메인 영역에 대한 자원을 출력해주는 것이기 때문에 의존해도 상관없다고 생각했기 때문이다... 🥲 당연하게도 이 부분에 대한 리뷰를 받게 되었다.

public enum PieceName {
    QUEEN(PieceType.QUEEN, 'Q'),
    ROOK(PieceType.ROOK, 'R'),
    KNIGHT(PieceType.KNIGHT, 'N'),
    PAWN(PieceType.PAWN, 'P'),
    BISHOP(PieceType.BISHOP, 'B'),
    KING(PieceType.KING, 'K');
}

문제가 되었던 코드이다. pieceName은 각 기물들을 출력하기 위한 메시지를 가지고 있으며, 여기서 PieceType은 도메인 영역의 enum이기 때문에 view 패키지 내부에 있는 PieceNamer과 도메인 영역의 PieceType의 결합도가 증가하는 것이다.

 

사실 처음 리뷰를 받았을 때는, 뷰가 도메인을 의존해서는 안 되는 이유에 대해 잘 이해하지 못했었다.

리뷰어님은 이에 대해서 다음과 같이 정의해주셨다.

- 뷰가 도메인을 의존하게 되면 도메인을 자유롭게 변경할 수도 없게 되고, view는 변경이 잦은데 도메인은 코어한 영역이라 여러 곳에서 쓰게 되는데 많은 곳이 영향받게 됩니다.
- 비지니스 요구사항의 변경으로 도메인이 변경될 때, api 도 불필요하게 변경되야하는 상황도 생깁니다.
- 하위호환성으로 사용자가 버전업데이트를 하지 않는 이상 외부로 나가버린 도메인필드는 변경이 불가능할 수도 있어요.

아직 레벨 1 단계에서는 겪기 어려운 문제지만... 여러모로 생각을 해보았다.

만약 현재 요구사항에서 '특별한 체스게임'을 만들라는 게 요구사항이 되어서, 도메인의 PieceType이 아예 달라지게 된다면 어떻게 될까? view 영역 역시 함께 수정될 수밖에 없다. 하지만, 만약 지금 버전이 배포가 되었다면 어떻게 될까?

 

이미 외부로 배포가 나간 이상, 해당 필드는 사용자의 업데이트에 달리게 된다. 사용자에게 강제로 버전 업데이트를 시키기 전까지 해당 도메인은 수정이 불가능한 상태가 되는 것이다. (그래서 보통 애플리케이션들이 버그 사항에 대해 강제 업데이트를 진행하는 건가 싶기도 하고...)

 

반면에, view에 대해서 완전히 의존성을 끊어주면 어떻게 될까? 도메인에 대한 기능이 변경되더라도 뷰에는 영향을 미치지 않게 된다. 아래는 피드백을 받아 수정한 코드이다.

public enum PieceName {
    QUEEN("QUEEN", 'Q'),
    ROOK("ROOK", 'R'),
    KNIGHT("KNIGHT", 'N'),
    PAWN("PAWN", 'P'),
    BISHOP("BISHOP", 'B'),
    KING("KING", 'K');
}

값을 String으로 가지고 있기 때문에 도메인이 변경되더라도 우선 배포가 나간 부분에 대해서는 그대로 사용할 수 있게 된다. (어떠한 도메인과도 의존을 맺지 않고 있는 상태) 물론, 원하는대로 동작시키기 위해서는 당연히 배포에 대한 수정본을 받아야 하지만, 새로운 도메인이 추가되었을 때 조금 더 유연하게 대응할 수 있게 되는 것이다.

 

내 나름대로 정의한 부분이기 때문에 옳은지는 모르겠지만, 리뷰어님은 레벨이 올라가면 자연스럽게 알게 될 내용이라고 하셨다. 

나도 의식적으로 코드를 작성할 때 도메인과 뷰 사이의 상호 참조를 줄일 수 있도록 만들어야겠다.

 

---

💬 폰의 움직임에 대하여

아마 많은 크루들이 이 부분에 대해서 어려워했을 것 같다. 나 역시도 폰의 움직임 때문에 구조를 여러 번 변경했다.

처음에는 'Piece'라는 클래스에 대해서 모든 기물들이 해당 기물을 상속받도록 진행했다. (Piece는 추상 클래스)

대략 이런 구조였다. 하지만 딱 봐도 이상하다. 각 기물들이 내부 정적 필드로 Move의 구현체에 대해 가지고 있었던 것이다.

public class Rook extends Piece {

    private final RookMove rookMove = new RookMove();

    public Rook(final PieceType pieceType, final CampType campType) {
        super(pieceType, campType);
    }

    @Override
    public boolean canMove(final Position source, final Position target) {
        return rookMove.canMove(source, target);
    }

    @Override
    public boolean canAttack(final Position source, final Position target) {
        return rookMove.canAttack(source, target);
    }

    @Override
    public boolean isPossibleRoute(final Position source, final Position target, final boolean isPossible) {
        return rookMove.isPossibleRoute(source, target, isPossible);
    }
}

이런 구조로 모든 말들이 이루어져 있으며, 기물의 움직임에 대해서 bypass를 하는 방식이었어서 의미없는 객체였다.

사실 이번 미션에서도 인스턴스 필드의 개수를 2개 이하로 줄이려다보니까 이런 사단이 났다... 💦

new Rook(PieceType.ROOK, campType);

외부에서는 이런 식으로 초기화를 했었다.

 

하지만, PieceType이라는 enum을 가지고 있기 때문에 각 기물에 대한 타입 정보가 이미 있고, 정적 변수로 Move를 초기화해주는 것은 다형성 측면에서도 결합도가 너무 증가하기 때문에 구조를 완전히 변경하였다.

인스턴스 필드의 개수 제한을 포기하고, 외부에서 기물을 생성할 때 PieceType과 Movable (기존의 Move, 인터페이스이기 때문에 이름을 -able과 같은 형태로 만들었다.)을 주입하는 식으로 진행하였다.

또한, Piece를 추상 클래스로 선언하지 않고 일반 클래스로 전환하였으며, 이렇게 하면 모든 기물에 대해 'Piece'라는 클래스로 접근이 가능하기 때문에 이전보다 알맞은 추상화 레벨을 가지게 된다.

 

또한, 구조를 바꾸면서 외부에서 pawn에 대해 체크할 필요가 없어졌다.

이전에는 'ChessGame'이라는 객체에서 움직임을 진행할 때 pawn의 움직임에 대해서 별도의 로직을 실행했었다.

// source -> target으로 체스말을 이동시키는 메서드.
private void play(final Position source, final Position target) {
    final Piece piece = chessBoard.checkPiece(source);
    validateCamp(piece);
    validateTargetSameCamp(target);
    validateObstacle(source, target, piece);
    if (validateAttack(source, target, piece)) {
        return;
    }
    if (checkPawnMove(source, target, piece)) {
        return;
    }
    movePiece(source, target, piece);
}

private boolean checkPawnMove(final Position source, final Position target, final Piece piece) {
    if (piece.isPawn() && piece.canMove(source, target)) {
        validatePawnMove(source, target, piece);
        return true;
    }
    return false;
}

private void validatePawnMove(final Position source, final Position target, final Piece piece) {
    if ((piece.isSameCamp(CampType.WHITE) && source.isRankSame(WHITE_PAWN_FIRST_MOVE)) ||
            (piece.isSameCamp(CampType.BLACK) && source.isRankSame(BLACK_PAWN_FIRST_MOVE))) {
        movePiece(source, target, piece);
        return;
    }
    if (Math.abs(target.calculateRankGap(source)) != PAWN_FIRST_MOVE) {
        throw new IllegalArgumentException("폰은 처음 이후 1칸만 전진할 수 있습니다.");
    }
    movePiece(source, target, piece);
}

기존에 작성했던 코드이다. 지금 봐도 왜 이렇게 짠 걸까 싶기는 했으나...

폰의 이동의 경우 대각선 앞에 있는 위치에 대해서만 공격이 가능하며, 이를 판단하기 위해서는 보드에 대한 정보가 필요했기 때문에 chessGame에서 이를 판단하도록 진행했었다. (또한, 현재 플레이하고 있는 진영에 대한 정보도 필요했던 상태)

기존에는 canMove, canAttack가 단순히 위임하는 메서드다 보니까 이런 식으로 진행했었던 것 같다.

 

public void play(final Position source, final Position target) {
    validateCamp(source);
    validateTargetSameCamp(target);
    validateObstacle(source, target);
    if (!canAttack(source, target) && !canMove(source, target)) {
        throw new IllegalArgumentException("이동할 수 없는 위치입니다.");
    }
    movePiece(source, target);
    currentCamp = currentCamp.changeTurn();
}

private boolean canAttack(final Position source, final Position target) {
    final Piece sourcePiece = chessBoard.getPiece(source);
    final boolean isTargetExist = chessBoard.contains(target);
    return sourcePiece.canAttack(source, target, isTargetExist);
}

private boolean canMove(final Position source, final Position target) {
    final Piece piece = chessBoard.getPiece(source);
    boolean isTargetExist = chessBoard.contains(target);
    return piece.canMove(source, target, isTargetExist);
}

하지만, 구조를 변경하면서 위와 같이 pawn이라는 조건을 외부에서 판단할 필요가 없어졌다.

piece에서 pieceType을 가지고 있기 때문에 기물에게 본인이 폰인지 물어볼 수 있게 되었고, 이를 통해 폰의 특별한 움직임에 대한 조건을 추가해줄 수 있기 때문에 외부에서는 기물이 움직이기 위해 어떤 조건이 필요한지 알 필요가 없게 되었다.

물론, 인자로 isTargetExist를 통해 도착 지점에 기물이 있는지를 체크하는 변수가 들어가지만, 로직 자체가 외부에 있는 것보다는 기물 자체가 인자로 받은 값들을 바탕으로 본인이 움직일 수 있는지 판단하는 현 구조가 더 낫다고 생각했다.

 

// Piece.java
public boolean canMove(final Position source, final Position target, final boolean isTargetExist) {
    if (pieceType == PieceType.PAWN && movable.canMove(source, target)) {
        validatePawnDirection(source, target);
        return validatePawnMove(source, target, isTargetExist);
    }
    return movable.canMove(source, target);
}

public boolean canAttack(final Position source, final Position target, final boolean isTargetExist) {
    if (pieceType == PieceType.PAWN) {
        validatePawnDirection(source, target);
        validatePawnCanAttack(source, target, isTargetExist);
    }
    return movable.canAttack(source, target);
}​

Piece에서 선언한 메서드이다. 위와 같이 폰인 경우 검증 조건을 추가하여서 폰이 움직일 수 있는 조건에 대해서 체크하였다.

 

코드로 작성하고 나니까 변경이 없는 것 같지만... 이 구조까지 오는 게 상당히 힘들었다 🥲

물론 더 좋은 구조가 있을 것 같지만, 현 구조에서는 이렇게 만드는 것이 최선이 아닐까 싶다...

 

---

💬 커맨드 패턴 적용하기

이번 미션에서 적용한 새로운 디자인 패턴이다. 사실 이 부분은 다른 크루들이 적용한 것을 보고 도입해보면 좋을 것 같아 적용하였다.

start, status, move, end, 총 4가지 경우에 대해 사용자에게 입력을 받을 수 있기 때문에 각각을 하나의 컨트롤러에서 처리하기에는 분기문이 굉장히 많아질 것 같다는 생각이 들었다. 그래서 다음과 같은 구조를 두었다.

이 구조의 장점은 컨트롤러를 가볍게 가져갈 수 있다는 점이다.

(나 같은 경우는 각각의 상태를 xxxController라는 이름으로 지었기 때문에, 메인으로 진행하는 컨트롤러의 이름을 ChessHandler로 지었다. 각각의 컨트롤러를 선택한다는 의미로 핸들러로 지은 건데 리뷰어님이 추천해주셨다.)

// ChessHandler.java
public void run() {
    final long userId = getUserId();
    OutputView.printStartMessage();
    Controller controller = new StartController(chessGameService);
    while (controller.isRun()) {
        controller = play(controller, userId);
    }
}

private Controller play(Controller controller, final long userId) {
    try {
        final List<String> commands = InputView.getCommands();
        final Command command = Command.findCommand(commands);
        controller = controller.checkCommand(command, userId);
        final Optional<ChessGame> chessGame = controller.findGame(userId);
        chessGame.ifPresent(game ->
                OutputView.printBoard(ChessBoardDtoMapper.createChessBoardDto(game.getChessBoard())));
        return controller;
    } catch (IllegalArgumentException e) {
        OutputView.print(e.getMessage());
        return play(controller, userId);
    }
}

최종 코드를 가져오다 보니까 userId나 그런 것들이 보이지만...

중요한 부분은 controller.isRun()을 통해서 게임의 진행 상태에 대해서 체크하고, 공통적으로 진행해야 하는 사용자의 커멘드 체크 (checkCommand)나 findGame (진행 중인 체스 게임을 찾는 부분인데, 단계가 추가되며 만든 메서드이다 ㅎㅎ) 등을 공통적으로 호출할 수 있게 된다.

@Override
public Controller checkCommand(final Command command) {
    if (command.isStart()) {
        throw new IllegalArgumentException("이미 시작이 완료되었습니다.");
    }
    if (command.isEnd()) {
        return new EndController();
    }
    if (command.isStatus()) {
        return new StatusController(userId, chessGameService).getStatus(true);
    }
    return move(command);
}

또한, 각각의 컨트롤러들은 사용자가 잘못된 명령어를 입력하였거나, 사용자가 입력한 명령어에 따라서 상태를 변경할 수 있게 된다. 

위 코드는 MoveController이며, 만약 move 상태에서 사용자가 start를 입력하면 오류 메시지를, end를 입력하면 종료하도록 제어를, status를 입력하면 통계 정보를, 그게 아니라면 움직임에 대한 로직을 실행하도록 제어하였다.

 

사실 커맨드 패턴의 경우 크루들 사이에서도 도입에 대해서 많이 갈리는 부분이다.

오히려 이런 식으로 예외를 터트리거나 분기 처리를 모든 컨트롤러에서 진행하는 게 불필요하다는 의견도 있고, 현 구조상으로는 상태가 그렇게 많지 않기 때문에 하나의 컨트롤러에서도 충분히 처리가 가능하다는 것이다.

나 역시도 start -> move로 위임하기 위해서 인스턴스 필드를 공유하는 등, 불필요한 코드가 들어가다 보니 빼는 것에 대해서도 고민을 했었다. (물론, 이것보다 분기 처리가 더 힘들 것 같아서 커맨드 패턴을 유지했었지만...ㅎㅎ)

 

취향에 따라 갈리는 문제이기 때문에, 혹여나 도입하겠다면 잘 고려해보고 사용하는 게 좋을 것 같다 😊

 

+) Controller는 특정한 사용자, 혹은 상태와 결합해서는 안 된다. 

기존에는 UserId나 chessGame 같은 특정한 인스턴스를 필드로 가지고 있도록 만들었었는데, 생각해보면 컨트롤러의 경우 사용자의 요청이 들어왔을 때 응답을 해야 하는데 특정한 사용자에게 결합을 해버리면 책임이 맞지 않기 때문이다.

Controller는 외부에서 들어오는 input 값에 대한 처리, 외부로 나갈 output에 대한 처리, 적절한 service를 호출하는 곳이라는 것을 항상 명심하도록 하자 😎

 

---

💬 DTO는 어디에서 변환해야 할까?

public final class BoardDto {

    private final Map<PositionDto, PieceDto> board;

    private BoardDto(final Map<PositionDto, PieceDto> board) {
        this.board = board;
    }

    public static BoardDto from(final Map<Position, Piece> board) {
        final Map<PositionDto, PieceDto> boardDto = new HashMap<>();
        for (Position position : board.keySet()) {
            boardDto.put(PositionDto.from(position.getRank(), position.getFile()),
                    PieceDto.from(board.get(position)));
        }
        return new BoardDto(boardDto);
    }

    public Map<PositionDto, PieceDto> getBoard() {
        return Collections.unmodifiableMap(board);
    }
}

사실 레벨 1 미션을 진행하면서 'Dto를 사용할 필요가 있을까?'라는 생각을 했었는데, 체스 미션을 하면서 처음으로 사용하게 되었다.

현재 위의 코드는 체스판에 대해 view가 출력하기 위해 dto로 변환하는 로직인데, 리뷰어님은 dto가 도메인을 모르도록 만드는 건 어떠냐고 여쭤보셨다. 그래서 또 한 번 고민의 시간을 거치게 되었다. 왜 DTO가 도메인을 몰라야 할까...?

 

사실 처음 리뷰를 받았을 때는 service layer를 생성해서 해당 계층에서 변환을 하라는 말로 받아들였다.

마틴 파울러가 말한 Service Layer의 정의를 보았을 때, Service는 애플리케이션의 경계 정의 및 비즈니스 로직 등, 도메인에 대한 캡슐화를 진행하는 곳이라고 했기 때문이다. 만약 컨트롤러에서 DTO로 변환하는 로직이 생긴다면, 도메인의 변경이 컨트롤러에게도 영향을 끼치게 되기 때문에 캡슐화가 깨지게 되어 Service Layer에서 하는 게 맞다는 생각이 들었다.(테코블 감사합니다 🙇‍♀️)

public final class ChessBoardService {

    private final PieceService pieceService;
    private final PositionService positionService;

    public ChessBoardService(final PieceService pieceService, final PositionService positionService) {
        this.pieceService = pieceService;
        this.positionService = positionService;
    }

    public ChessBoardDto createChessBoardDto(final Map<Position, Piece> chessBoard) {
        final Map<PositionDto, PieceDto> boardDto = new HashMap<>();
        for (Position position : chessBoard.keySet()) {
            boardDto.put(
                    positionService.createPositionDto(position.getRank(), position.getFile()),
                    pieceService.createPieceDto(chessBoard.get(position)));
        }
        return new ChessBoardDto(boardDto);
    }
}

그래서 요런 이상한 코드를 작성하게 되었다 😅

 

하지만, 리뷰어님이 다음과 같은 의견을 주셨다.

현재 서비스를 dto를 만드는 factory처럼 사용하고 계시는데요ㅎㅎ.. 서비스의 역할은 이게 아닙니다.
서비스의 역할을 찾아보시면 좋을 것 같아요.
서비스는 비지니스 로직의 흐름을 담당하는 클래스입니다. dto를 만드는 factory 역할을 하는게 아닙니다!
원래는 서비스가 없다면 Controller에서 비지니스 로직을 호출하여 사용하게 될텐데요. 애플리케이션이 커지면, 복잡해지기 때문에 이런 흩어진 로직을 하나로 묶어서 고수준의 형태로 추상화해서 사용하는 것이 서비스입니다.
따라서 비지니스 로직의 흐름을 고수준으로 묶기 때문에 서비스의 메서드는 하나의 applicaiton 의 기능을 하게 되는것이죠.

현재 내가 작성한 코드는 mapper 기능 그 이상, 그 이하도 하지 않고 별도의 비즈니스 로직 역시 존재하지 않았기 때문이다.

그래서 아예 mapper라는 이름의 util 클래스를 생성하여 해당 클래스에서 변환을 담당하도록 변경하였다.

public final class ChessBoardDtoMapper {

    public static ChessBoardDto createChessBoardDto(final Map<Position, Piece> chessBoard) {
        final Map<PositionDto, PieceDto> boardDto = new HashMap<>();
        for (Position position : chessBoard.keySet()) {
            boardDto.put(
                    PositionDtoMapper.createPositionDto(position.getRank(), position.getFile()),
                    PieceDtoMapper.createPieceDto(chessBoard.get(position)));
        }
        return new ChessBoardDto(boardDto);
    }
}

이렇게 구현한 덕분에 도메인과 dto 사이의 의존성은 완전히 끊어지게 되었다.

코드를 작성하면서 서비스 레이어의 역할에 대해서도 다시 고민을 하게 되었다.

 

그냥 한 마디로 정리하면 비즈니스 로직의 집합 + 그리고 추상화의 목적.

서비스 레이어는 하나의 기능으로서, 비즈니스 로직의 흐름을 담당하게 된다.

 

두 번째로, 리뷰어님의 의견과 덧붙여서, 왜 dto는 도메인을 알면 안 되는지에 대한 의견은 다음과 같이 정리했다.

dto의 의미론적 관점으로 생각해보았을 때, dto는 view와 controller 사이에서 도메인의 의존을 끊기 위해 사용한다.

하지만 dto가 도메인을 알고 있다면, dto의 의미 자체가 퇴색된다. 단순히 getter, setter를 통해 값을 채워주고, 값을 반환하는 로직만 필요할 뿐이고, 필요한 곳에 데이터를 전달해주는 역할로 충분하다.

 

+ 추가적으로, 그렇다면 enum 도메인에 대해서도 dto로 변환해야 할까? 라는 고민도 진행했다.

현재 사용되고 있는 pieceType의 경우 본 애플리케이션에서 중요한 도메인이기도 하고, '도메인'으로서 역할을 하고 있기 때문에 dto로 변환하여 반환하는 게 맞을 것 같다는 결론을 내렸다. 

public final class PieceDto {
    private final String pieceType;
    private final String campType;

    public PieceDto(final String pieceType, final String campType) {
        this.pieceType = pieceType;
        this.campType = campType;
    }
}

그래서 enum 타입인 pieceType, campType에 대해서는 String으로 변환을 진행하였다.

 

---

💬 단위 테스트와 통합 테스트

4단계 미션에서 DAO와 관련된 테스트를 다음과 같이 작성하였다.

public class MockChessGameDao implements ChessGameDao {
    private final Map<Long, ChessGameEntity> STORAGE = new ConcurrentHashMap<>();
    private final AtomicLong pk = new AtomicLong(0L);

    @Override
    public Optional<ChessGameEntity> findByUserId(final long userId) {
        return STORAGE.values().stream()
                .filter(chessGameEntity -> chessGameEntity.getUserId().equals(userId))
                .map(chessGameEntity -> new ChessGameEntity(chessGameEntity.getId(), chessGameEntity.getCurrentCamp(),
                        chessGameEntity.getUserId()))
                .findFirst();
    }

    @Override
    public Long insert(final ChessGameEntity chessGameEntity) {
        final long key = pk.addAndGet(1L);
        final ChessGameEntity savedChessGameEntity = new ChessGameEntity(key,
                chessGameEntity.getCurrentCamp(), chessGameEntity.getUserId());
        STORAGE.put(key, savedChessGameEntity);
        return pk.longValue();
    }

    @Override
    public void updateCurrentCampById(final long id, final CampType currentCamp) {
        final ChessGameEntity chessGameEntity = STORAGE.get(id);
        STORAGE.put(id, new ChessGameEntity(chessGameEntity.getId(), currentCamp.name(), chessGameEntity.getUserId()));
    }

    @Override
    public void deleteByUserId(final long userId) {
        STORAGE.keySet().stream()
                .filter(key -> Objects.equals(STORAGE.get(key).getUserId(), userId))
                .forEach(STORAGE::remove);
    }
}

Map을 통해서 가짜 스토리지를 만들고, 실제 DB 연산이 수행되는 것처럼 만들었다.

Test Double 기법의 Fake를 사용했다고 볼 수 있다.

하지만 몇몇 크루들은 실제로 DB 연결에 대한 테스트 코드를 작성하고, DB를 롤백하는 형태로 작성하여서 이런 식으로 작성하는 게 올바른 의도인지가 궁금했다. 리뷰어님은 이에 이렇게 답해주셨다.

db와 연결하여 통합테스트를 작성하려는 의도가 아니고, 유닛테스트를 작성하시려고 하는 의도라면 이렇게 작성하셔도 무방하다고 생각합니다!

통합 테스트와 단위 테스트...?

나는 지금까지 기능별로 테스트 하는 것은 단위 테스트 (ex. 도메인 영역), 기능이 모아진 부분을 테스트하는 것을 통합 테스트 (ex. 컨트롤러)라고 생각했었다. 리뷰어님의 답변을 받고 내가 잘못 생각하고 있었다는 것을 깨닫고, 내 나름대로 두 테스트에 대한 정의를 내려보았다.

 

그리고 리뷰어님은 이에 대해서 다음과 같이 대답을 해주셨다.

가장작은 단위로 다른 협력객체 없이 테스트를 한다면, 단위테스트
테스트를 진행할 시 협력객체를 통해 테스트를 진행하면 통합테스트

테스트하는 대상 이외의 것을 외부의 리소스라고 본다면 지금까지 생각했던 테스트의 개념과 어느 정도 부합하는 것 같기도 하다.

현재 프로그램을 넘은 외부 리소스 (ex. 외부 api, DB) 등이 포함되어야 통합 테스트인 건가?라고 생각했었는데, 그 관점보다는 내가 구현한 기능에서 외부 리소스를 사용해야 할 때, 해당 리소스를 mocking을 해서 실제로 테스트 하는 동작이 하나의 기능이라면 단위 테스트라고 볼 수 있을 것 같다.

 

즉, mocking을 통해 외부의 리소스를 제외시키고 내가 테스트할 대상에 대해서만 테스트한다면 이는 단위 테스트가 되는 것이고,

그게 아니라 실제 협력 객체 자체와 함께 테스트를 진행한다면 통합 테스트로 볼 수 있을 것 같다!

 

그래서 만약 스프링에서 h2 같은 in-memory database를 활용하여 repository를 테스트한다면, 실제 DB 리소스와 연결이 생기기 때문에 통합 테스트라고 볼 수 있다! 반면에, 소셜 로그인 같이 외부 api 연동을 mocking하여 패스하게 된다면 해당 테스트는 단위 테스트가 된다. 이 기회에 두 개념을 명확하게 잡은 것 같아서 뿌듯했다...!

 

---

바쁘게 진행했던 만큼 뿌듯했던 체스 미션... 🥹

조금 더 리뷰어님이랑 많은 대화를 나눴다면 좋았을 텐데 아쉬움이 남는다.

그래도 후회는 없다! 다음 미션 때는 더 열심히 진행해야겠다.