🐰 [flowbit] #9. 실패 케이스 테스트 - 깨지는 상황까지 검증하기

☘️ 1. 오늘 목표

어제는 배포를 준비하기 위해
Controller 기준의 최소 테스트 코드를 작성했다.

정상 요청을 보내면
정상 응답이 오는지 확인하는 테스트였다.

하지만 테스트 코드는
성공하는 경우만 확인하면 부족하다.

실제 서비스에서는
잘못된 요청도 들어오고
존재하지 않는 데이터를 조회하는 경우도 생긴다.

그래서 오늘 목표는 명확했다.

실패하는 상황도 테스트하자

---

☘️ 2. 왜 실패 케이스 테스트가 필요한가

기능이 정상적으로 동작하는지 확인하는 것도 중요하지만
그만큼 중요한 게 있다.

문제가 생겼을 때 서버가 어떻게 응답하는가

예를 들어 존재하지 않는 작업을 조회했을 때
서버가 그냥 500 에러로 터지는 것과

명확하게 에러 메시지를 내려주는 것은 다르다.

GET /api/tasks/999

이런 요청이 들어왔을 때

"작업을 찾을 수 없습니다."

처럼 예측 가능한 응답을 내려줘야 한다.

---

☘️ 3. 기존 예외 처리 구조 확인

Flowbit에는 이미 전역 예외 처리 구조가 있었다.

GlobalExceptionHandler에서
Controller 전역에서 발생하는 예외를 처리하고 있었다.

현재 구조는 다음과 같다.

@ExceptionHandler(IllegalArgumentException.class)
public ErrorResponse handleIllegalArgumentException(IllegalArgumentException e) {
    return new ErrorResponse("BAD_REQUEST", e.getMessage());
}

그리고 응답은 다음 구조로 내려간다.

{
  "code": "BAD_REQUEST",
  "message": "작업을 찾을 수 없습니다.",
  "timestamp": "..."
}

즉 오늘은 새 구조를 만드는 것이 아니라
기존 예외 응답 구조에 맞춰 테스트를 추가하는 작업이었다.

---

☘️ 4. 존재하지 않는 Project 테스트

먼저 존재하지 않는 프로젝트를 조회하는 테스트를 추가했다.

@Test
@DisplayName("존재하지 않는 프로젝트 조회 시 400을 반환한다")
void getProject_notFound() throws Exception {
    when(projectService.getProject(999L))
            .thenThrow(new IllegalArgumentException("프로젝트를 찾을 수 없습니다."));

    mockMvc.perform(get("/api/projects/999"))
            .andExpect(status().isBadRequest())
            .andExpect(jsonPath("$.code").value("BAD_REQUEST"))
            .andExpect(jsonPath("$.message").value("프로젝트를 찾을 수 없습니다."))
            .andExpect(jsonPath("$.timestamp").exists());

    verify(projectService).getProject(999L);
}

이 테스트는
/api/projects/999 요청이 들어왔을 때
없는 프로젝트라면 BAD_REQUEST 응답이 내려오는지 확인한다.

---

☘️ 5. 존재하지 않는 Task 테스트

Task도 동일하게 실패 케이스를 추가했다.

@Test
@DisplayName("존재하지 않는 작업 조회 시 400을 반환한다")
void getTask_notFound() throws Exception {
    when(taskService.getTask(999L))
            .thenThrow(new IllegalArgumentException("작업을 찾을 수 없습니다."));

    mockMvc.perform(get("/api/tasks/999"))
            .andExpect(status().isBadRequest())
            .andExpect(jsonPath("$.code").value("BAD_REQUEST"))
            .andExpect(jsonPath("$.message").value("작업을 찾을 수 없습니다."))
            .andExpect(jsonPath("$.timestamp").exists());

    verify(taskService).getTask(999L);
}

정상 조회뿐 아니라
없는 작업을 조회했을 때의 응답도 테스트하게 되었다.

---

☘️ 6. 상태 변경 실패 케이스

작업 조회뿐 아니라
상태 변경 API도 실패 케이스를 추가했다.

PATCH /api/tasks/999/start
PATCH /api/tasks/999/complete
PATCH /api/tasks/999/block
PATCH /api/tasks/999/delete

존재하지 않는 작업을 시작하거나
완료하거나
보류하거나
삭제하려고 할 때

모두 같은 방식으로 예외 응답이 내려오는지 확인했다.

---

☘️ 7. 잘못된 status 파라미터 처리

추가로 잘못된 status 값이 들어오는 경우도 처리했다.

GET /api/tasks?status=INVALID_STATUS

TaskStatus는 정해진 enum 값만 받을 수 있다.

TODO
IN_PROGRESS
BLOCKED
DONE
DELETED

그 외의 값이 들어오면
파라미터 변환 과정에서 예외가 발생한다.

그래서 MethodArgumentTypeMismatchException을 전역 예외 처리에 추가했다.

@ResponseStatus(HttpStatus.BAD_REQUEST)
@ExceptionHandler(MethodArgumentTypeMismatchException.class)
public ErrorResponse handleMethodArgumentTypeMismatchException(MethodArgumentTypeMismatchException e) {
    return new ErrorResponse("BAD_REQUEST", "요청 파라미터 값이 올바르지 않습니다.");
}

이제 잘못된 status 요청도
일관된 에러 응답으로 처리된다.

---

8. 테스트 실행

테스트 작성 후 다시 실행했다.

./gradlew test

결과:

BUILD SUCCESSFUL

성공 케이스뿐 아니라
실패 케이스까지 포함한 테스트가 통과했다.

---

☘️ 9. 오늘 정리

오늘은 새로운 기능을 만든 날은 아니었다.

대신 기존 API가
잘못된 요청을 받았을 때
어떻게 반응하는지 검증했다.

오늘 작업한 내용은 다음과 같다.

Project 실패 케이스 테스트 추가
Task 실패 케이스 테스트 추가
상태 변경 실패 케이스 테스트 추가
잘못된 status 파라미터 예외 처리 추가
GlobalExceptionHandler 테스트 적용

---

☘️ 10. 현재 상태

Flowbit은 이제

정상 요청이 들어왔을 때 동작하고
잘못된 요청이 들어왔을 때도 예측 가능한 응답을 내려준다.

즉,

성공하는 API에서

실패도 처리할 수 있는 API로

한 단계 넘어갔다.

---

☘️ 11. 다음 목표

이제 테스트 코드도 최소한의 성공/실패 케이스를 갖췄다.

다음 단계는 다시 배포다.

EC2 서버 생성
Spring Boot 서버 배포
도메인 연결
CI/CD 구성

로컬에서 동작하는 프로젝트를 넘어
실제 환경에서 접근 가능한 서비스로 만드는 단계로 들어간다.