TDD 스터디 회고: 에러 핸들링의 책임과 TDD의 본질

안녕하세요, 저는 현재 TDD 스터디를 진행하고 있는 개발자입니다.
오늘은 이번 주 스터디를 하면서 고민했던 내용들을 여러분과 공유하고자 합니다.

1. 에러 핸들링도 하나의 '책임' 이다

기획 해체 후 만든 카테고리 수정 기능명세서

이번 주에 저번처럼 기획을 기능 명세서로 만든 후,
기능 명세서에서 명시한 Exception을 어느 계층에서 던져야 할지 고민이 되더라고요.

이전까지는 Controller에서 DTO를 바인딩할 때 @Valid로 모든 검증을 처리했었거든요.
필드가 유효하지 않은 값이 있다면, 서비스 로직까지 아얘 오면 안된다고 생각했기 때문입니다.

누가 책임질거야

서비스 계층은 비즈니스 로직을 책임지는 계층이지,
값의 유효성에 대한 검증의 책임은 컨트롤러에 있다고 생각하기 때문입니다.

그래서 위 카테고리 수정 명세서를 예시로 들어보자면,
'name'으로 빈 값이 들어오는 경우나, 최소/최대 길이를 어기는 값이 들어올땐
controller 계층에서 걷어내야 한다고 생각합니다.

박우빈좌께선 이의 있소,,

그런데 박우빈님의 강의에서는 Controller는 필드 자료형의 최소한의 검증(ex. String이면 @NotBlank)만 하고,
비즈니스적 검증(ex. 설명의 길이는 최소 10, 최대 50 이하)은 Service 계층에서 하는 게 좋다는 말씀이 나옵니다.

빈 String 값은 해당 자료형이 가져야 하는 최소한의 보장이고,
해당 String 필드가 최소 몇자, 최대 몇자여야 한다! 라는 건 비즈니스 로직이기에,
이를 Service 계층에서 검증을 하는 게 맞다! 라고 하시더라구요.

그래서 실제로 강의 방법대로 코드를 만들어보기도 했습니다.

Controller -> Service 호출 시 넘기는 객체, 서비스용 DTO 다

그렇다면 앞으로 검증은 서비스에도 따로 할건가요?

대답은 NO 입니다.

강의를 듣고 나서 팀원분과 이 부분에 대해 얘기를 해봤습니다.
팀원분은 유효하지 않은 값이라면 애초에 Service 까지 올 필요가 없다고 생각하시더라구요.
유효하지 않는 케이스이기 때문에, 빨리 내보내는 게 맞다는 거죠.

그리고 저도 이분과 동일한 생각입니다.
만약에 유효하지 않은 값이라면, 얼른 내보내고 서버의 자원을 아끼는 게 좋다! 라는 생각입니다.

그래서 우빈님과는 다른 노선을 타겠지만, 에러를 던지는 것도 하나의 책임이고, 
이를 누가 가져가냐를 생각할 수 있었던 좋은 경험이었습니다!

TDD 의 본질이란?

솔직히 말하면 이번 주 스터디 분량이 많아서 벅찼습니다.

저희 팀은 현재 정해진 강의 진도를 듣고, 기획명세서를 작성한 뒤
TDD로 프로젝트를 구현하는 방식으로 스터디를 진행하거든요.
스터디 방식 : 2024.05.01 - [About Me/회고] - TDD 스터디 주간 회고 (4/22 ~ 4/28)

기존의 프로세스와 반대이다!

명세서 분석부터 코딩까지 다 하려니 시간이 오래 걸리더라고요.
TDD가 익숙하지 않아서 그런 것도 있겠지만,
애초에 TDD 자체가 사람의 자연스러운 문제 해결 흐름과는 반대라서 시간이 많이 드는거 같아요.

그래서 하면서도 참 미묘했습니다. 좋았다가 안 좋았다가를 엄청 반복했습니다.
명세서 작성할 때는 TDD 안 좋은거 같은데? 귀찮은 데?
회사에서 이걸 일일이 하고 있다고..? 언제..?

윽... 귀찮ㅇ...

하다가도 막상 코드 작성할 때는 명세서에 적힌 대로 코딩만 하면 되니까

하 편안 ^^**

코드에 대한 자기의심이 확실히 덜하다라는 생각이 들었습니다.
그래서 하고 내린 결론은 앞으로는 비즈니스가 급박한 게 아니라면

기획명세서 해체 → (테스트 코드 는 너무 급하면 놉) → 본 코드 작성

의 과정을 꼭 지켜볼 생각입니다.

특히 명세서 해체는 장점이 큰 것 같아요.
하면서 느끼는 건데 개인적으로 TDD 의 본질은 사실 Red -> Green -> Blue 가 아니라
기획명세서 해체가 필수 선수과정이 된다는 게 제일 장점이 아닐까... 라는 생각을 합니다 

마무리

이번 스터디 회고를 하니 제가 어떤 걸 고민하고 있는지 정리가 되네요.
혼자라면 깊이 생각 못 했을 내용들인데, 함께 토론하니 개발자로서 성장하는 것 같아요.
TDD, 쉽진 않지만 계속 연습해볼 거예요. 언젠가는 자연스러워지겠죠?

제 고민을 읽어주셔서 감사해요. TDD에 관심 있는 분들, 같이 얘기 나눠봐요. (진짜로)
다음에 또 유익한 이야기로 찾아오겠습니다!