[내일배움캠프_사전캠프_8기]_Days_17 TIL_ 팀 프로젝트-Day9

2026. 7. 14. 15:55부트캠프/TIL(Today I Learned)

오늘의 학습 키워드

  • Mockito
  • JUnit5
  • Test Code
  • CI/CD
  • Git Conflict
  • ApplicationContext
  • 협업 개발 프로세스

오늘 한 일

오늘은 팀 프로젝트 마무리 단계에서 테스트 코드를 작성하는 데 시간을 많이 썼다.

내가 맡은 도메인은 UserReview였기 때문에 회원가입 관련 기능과 리뷰 기능 위주로 테스트를 작성했다.

리뷰에서는 성공하는 경우만 확인한 것이 아니라 실제 서비스에서 충분히 발생할 수 있는 예외 상황을 중심으로 테스트를 만들었다.

예를 들어

  • 주문이 존재하지 않는 경우
  • 본인의 주문이 아닌 경우
  • 주문 상태가 COMPLETED가 아닌 경우
  • 이미 리뷰가 존재하는 경우

이런 케이스들을 하나씩 검증하면서 서비스 로직이 의도한 대로 동작하는지 확인했다.

특히 주문 상태가 COMPLETED일 때만 리뷰를 작성할 수 있도록 검증하는 부분도 테스트 코드로 직접 확인했다.

assertThatThrownBy(() -> reviewService.createReview(loginUser(1L), req))
    .isInstanceOf(CustomException.class)
    .hasFieldOrPropertyWithValue("errorCode", ErrorCode.ORDER_NOT_COMPLETED);
    

일반적인 assertThat()은 값을 검증.
assertThat(result).isEqualTo(10);
반면 assertThatThrownBy()는

"이 코드를 실행했을 때 예외가 발생해야 한다."

를 검증한다.

() -> reviewService.createReview(loginUser(1L), req)

이 코드를 실행했을 때 예외가 발생하는지를 확인.


() ->

이건 람다식(Lambda Expression)

원래는 이렇게 작성해야 한다.

try {
    reviewService.createReview(loginUser(1L), req);
} catch (Exception e) {

}

하지만 AssertJ는

"이 코드를 실행해 볼게."

라는 의미로 람다를 전달받는다.

관련 기능 테스트하면서 실패하는 상황 확인했다.

프로젝트를 마무리하면서 기능을 만드는 것보다 기능이 깨지지 않는다는 걸 증명하는 과정이 훨씬 중요하다는 걸 다시 느꼈다.


오늘 가장 오래 고민한 것

생각보다 테스트 코드보다 더 오래 붙잡고 있었던 건 CI였다.

PR을 올리면 CI가 계속 실패했고, 처음에는 코드가 문제인 줄 알았다.

하지만 원인을 하나씩 찾아보니

  • ApplicationContext 로딩 문제
  • Bean 생성 문제
  • 테스트 환경 설정
  • 의존성 충돌
  • Git 충돌

처럼 코드 외적인 이유도 정말 많았다.

CI가 실패하면 다시 수정하고,

다시 Push하고,

다시 실패하고,

로그를 읽고,

또 수정하는 과정을 정말 많이 반복했다.

오늘 하루만 보면 기능을 만든 시간보다 로그를 읽고 원인을 찾은 시간이 더 길었다.

솔직히 오늘은 기능을 많이 만든 날은 아니다.

하지만 개발을 하면서 기능을 만드는 것만큼 중요한 게 문제가 생겼을 때 원인을 찾는 능력이라는 걸 조금은 배웠다.

특히 CI 로그를 읽는 방법이나 ApplicationContext가 왜 뜨는지, 테스트 환경이 왜 달라지는지 같은 부분은 직접 겪어보지 않으면 잘 모르는 내용이었다.

Git 충돌도 여러 번 경험하면서

  • rebase
  • merge
  • reset
  • stash

같은 명령어를 다시 찾아보고 직접 사용해봤다.

혼자 프로젝트를 했다면 아마 이런 상황을 겪지 않았을 수도 있다.

하지만 팀 프로젝트에서는 다른 사람이 작업한 코드와 계속 합쳐지고, 충돌도 해결해야 하고, 테스트도 모두 통과해야 하기 때문에 협업이 얼마나 중요한지 체감했다.


오늘 회고

예전에는 개발자는 코드를 잘 짜는 사람이면 된다고 생각했다.

그런데 팀 프로젝트를 하면서 생각이 조금 바뀌었다.

실제로는

  • Git을 사용할 줄 알고
  • 충돌을 해결할 수 있고
  • CI를 통과시키고
  • 테스트 코드를 작성하고
  • 다른 사람 코드와 함께 돌아가도록 만드는 것

이런 과정이 훨씬 많았다.

오늘은 CI 때문에 시간을 정말 많이 썼지만 아깝다는 생각은 들지 않는다.

오히려 프로젝트가 끝난 뒤에도 가장 오래 기억에 남을 경험일 것 같다.

기능 하나를 더 만드는 것보다 문제 하나를 끝까지 해결했던 경험이 앞으로 취업해서도 더 도움이 될 거라고 생각한다.

 

내일 할 일

내일은 팀원들과 함께 각자 맡은 도메인에서 발표할 문서를 작성한다. 내일은 회의하는 시간이 길어질것같으니 오늘 문서를 작성하고 오늘 겪었던 것에  더 복습해본다.