주4회 해주세요 주4회 해주세요 주4회 해주세요 🥹

화요일부터 시작했던 행복했던 한 주가 마무리됐다. 다음 주에는 수요일이 또 빨간 날이라 잔뜩 기대 중 🥹 4일뿐인 한 주기는 했지만, 그만큼 밀도있었던 한 주였다. 모두가 미션하느라 바빠서 비교적 조용했던 잠실 캠퍼스를 지냈다! 어찌저찌 마무리가 되어가는 중이지만, 다시 이 코드를 들고 다음 미션을 하려니 숙연해지는 중… 🔥 이번 미션동안 담아갈 것을 잘 담아가자!

📋 여기저기 붙은 전단지, 테스트 하세요!

저번 주까지만 해도 테스트에 대한 이야기로 시끄러웠다. 통합 테스트를 진행해야 하는가? Mock을 사용해야 하는가? 등등등… 그 성원에 힘입어(?) 14층 곳곳에 전단지가 붙었다. 내용은 Mock을 사용하지 않고 테스트 충실도를 높이는 것이었다. 나 또한 어떤 테스트를 작성해야 할 지 감이 안 오던 상황이라, 재미있게 보았다 👀

테스트는 왜 할까? 얼마 전에 Ruby on rails의 dhh, 켄트 벡과 마틴 파울러가 TDD는 죽었는가? 에 대한 토론 영상을 봤다. 단위 테스트(Unit Test)의 단위의 정의가 스무 가지가 넘어간다는 이야기를 들으며, 단위를 어떻게 정하느냐에 따라서 테스트가 바뀔 수도 있겠구나, 싶었다.

사실 세 사람이 공통적으로 이야기하고 싶은 것 중 하나는 전단지의 내용과 일맥상통하는데, ‘Mock을 사용하지 말라’이다. 나도 테스트를 작성하면서 얻은 불편함에서 공감했다. 테스트가 틀렸을 때, 의심해야 하는 부분이 나의 프로덕션 코드뿐만 아니라 Mocking한 테스트 코드의 잘못인지, Fake Object의 로직 잘못인지를 생각해야 하는 수고가 너무 귀찮았기 때문이었다. 단순하게 의존성을 가지더라도 신뢰할 수 있는 실제 객체를 사용하면 좋지 않을까? 라는 생각을 가지고, 지금까지는 테스트를 진행할 때 의존성을 가져와서 썼다. 설령 테스트가 실패하더라도, 의존성 끝자락에 있는 실패한 테스트부터 하나씩 고쳐나가면 됐으니까.

하지만 이는 ‘Mock을 쓰면 안 된다’를 뒷받침한다. 조금 더 멀리서 바라보는 테스트에서 하고싶은 것이 무엇인지가 흐려진다. 테스트를 왜 할까? 테스트 코드를 통해 나의 코드가 온전함을 확신하고, 추후에 발생할 변동사항에 유연하게 대처하기 위해서라고 이야기할 수 있겠다. 이 측면에서 바라본다면, Mock을 쓰든 의존성을 끌어다 쓰든 코드를 작성하는 사람이 편안하다면 OK라고 볼 수 있지 않을까? 토론 영상에서도 테스트의 본질에 대해서 끊임없이 탐구하고, Mock을 하는 경우 어떤 부분이 불편하게 되는지를 자세히 설명해 줘 도움이 되었다 🤩

Tautological Test라는 용어도 있다. 간단하게 이야기하자면 Mock을 통해 리턴할 값을 검증하는(?) 테스트 실수인데, 생각보다 이런 상황이 ‘어떤 것을 테스트할지’를 헷갈리면서 발생하는데, 입력에 대한 출력을 고정할 수 있는 Mock의 경우 더욱 실수하기 잦다.

다시 돌아와서, 그렇다면 테스트를 작성할 때 어떤 것을 테스트할 것인가? 에 집중해 보자. Mock을 쓰는 것, 의존성을 가져다 쓰는 것 모두 위의 질문을 통해 대답하면 된다. 하나의 방법만을 고수할 것이 아니라, 테스트를 하는 여러 가지 방법 중에서 내가 테스트하고 싶은 부분을 적재적소에 활용하는 것이 중요하겠다.

기능을 작성했고, 테스트를 하고 싶다. 떠오르는 방법은 두 가지다. RestAssured를 활용한 E2E/Acceptance Test, Mock을 활용한 Controller Test. 당신은 어떤 테스트를 작성하겠는가? 앞의 문장을 읽고 별다른 문제를 느끼지 못 했다면, 테스트를 작성할 필요가 없는 기능일지도 모른다. 단순히 커버리지를 높이기 위한 테스트나, 어떤 것을 테스트할 지 모르는 테스트는 방해가 될 뿐이다.

다시 생각해 보자. ‘무엇을 검증하고 싶은가?’ 에 초점을 맞춰 보는 거다. 검증하려는 대상에 따라 통합 테스트가 될 수도, Mock을 활용한 단위 테스트가 될 수도 있다. 만약 Controller에서 일어나는 분기나 헤더에 담기는 내용을 것을 테스트하고 싶다면, 단순히 Service를 Mocking해 정말 해당 컨트롤러 메서드를 통해 Response가 온전히 담기는지를 테스트할 수 있다. 이걸로 원하는 테스트 목적을 이루게 된다. 반대로, 서비스를 사용하는 사람의 입장에서 전체적인 흐름을 시나리오로 작성하고, 이 발자취를 따라가보고 싶다면, 인수 테스트를 작성할 수 있다. 이때 RestAssured를 활용할 수 있게 되는 것이다. 단순히 ‘어? 이 메서드 테스트해야 하는데, 어떤 것을 써야 하지?’ 보다는, ‘if문에서 정말 잘 처리하고있는지를 확인해야겠어’ 와 같이 테스트를 할 내용을 구체적으로 적으면 윤곽이 드러날지도 모른다 😁

이런 내용을 알게된 뒤로, 테스트에 대한 신뢰가 더 깊어졌다. 테스트가 틀리는 이유도 명확해졌고, 디버깅을 할 때에도 어떤 부분을 봐야하는지가 메서드에서 보이니 쉽게 해결할 수 있었다. 테스트는 보다 쉬운 코드 변경을 위한 도구다. 적절히 사용하면 나의 코드에 확신을 가져다 주는 마법이지만, 불필요한 테스트를 남용한다면 필요한 것이 흐려져 되려 발목을 잡을 수 있겠다.

🛫 나날이 발전하는 데일리 미팅

점점 데일리 미팅이 개성있어지고 있다. 레벨 3부터는 이런 걸 못하니 지금이라도 실컷 즐기자(?) 느낌도 있는 듯. 저번에는 5v5 테트리스를 한 적도 있고, 1레벨 때 했던 맞춤법을 또 하기도 하고, 타자수 빠르게 입력하기도 있고, 확대된 로고 맞추기까지 재미있는 30분으로 찌뿌둥한 머리를 푼다ㅋㅋ

가끔씩 솔라가 마스터로 이끌어 정말 데일리 미팅을 하는 모습을 보여주기도 한다. 오늘 무슨 일을 할지, 얼마나 걸릴지 생각해서 크루들과 공유하고, 10분 남짓으로 빠르게 끝내는 것. 내가 지금 어떤 상황이고, 얼마나 빠르게 해결할 수 있는지를 인지함으로써 능률을 올려주는 방법이라고 생각했다 💡

🦆 오리와의 커피챗

이번 미션의 리뷰어 오리와 한 시간 남짓 이야기할 기회가 생겨 여러가지를 묻고 답하는 시간을 가졌다. ‘관습적으로 사용하는 코드를 경계’하는 방법에 대해서도 들어 보고, 저번 회고에 썼었던 @RestController에서의 불필요한 ResponseEntity에 대해서도 이야기했다. 나는 충분히 추상화 수준으로 설득될 수 있으리라 생각했는데, 오리의 입장은 달랐다. 프레임워크에서 제공한다면 이를 더 우선시해야 한다는 입장이다. 제공해주는데 왜 굳이 한 번 더 감싸..? 같은 느낌. 오히려 문서를 읽어본 팀원이라면 왜 이렇게 통일해야 했는지에 대한 의문을 가질 수도 있겠다.

Files Changed가 적은 PR일수록 오리에게는 좋은 PR이라고 한다. 정말 필요한 요구사항을 채워나가는 것을 통해 스프링을 잘 배워나가도록 하는 것이 목표인 듯하다. 블로그가 아닌, 공식 문서와 요구사항을 통해 객체지향을 얹은 코드가 실패할 리가 없으니, 나를 더 믿어보고 최대한 문서에 의존해 남은 코드를 작성하자고 마음먹게 됐다! ‘리팩터링은 요구사항이 아니다’ 라는 이야기를 들으면서 (다음 미션부터는 ㅎㅎ..) 정말 요구사항을 만족하는 것에만 집중하도록 생각할 수 있었다.

매번 적절한 브레이크와 실마리로 채워주신 덕분에 잘 나아가고 있다는 느낌을 받는다. 특히나 오고간 댓글도 많아서, 서로의 생각이 Discussion에 잘 드러난 점도 좋다 👍🏻 다양한 시각에서 생각해볼 수 있어서 좋은 경험을 하는 중이다. 특히 Interceptor-ArgumentResolver에서 공통적으로 나타나는 토큰 로직 단순화 등을 RequestScope, ThreadLocal 등의 키워드를 통해 자발적으로 공부할 수 있게 해주셔서 감사할 따름이었다 🥹 월요일에는 마감이니 하루동안 열심히 달려봐야지 🏃

🗣️ 이번 주는요

목요일에는 어김없는 테코톡이 이어졌다. 조이썬의 Optional, 감자의 웹 통신, 리니의 Https, 뽀로로의 캐싱까지 잘 들었다. 특히 리니가 테코톡 발등에 불 떨어졌다고 걱정하면서도 클라이밍에 청바지를 입고 함께하는 모습을 보였는데, 발표 때 정말 잘 풀어줘서 놀랐다. 이번 기수 유투부 조회수 1등을 노릴 만한 이야기였다.

금요일에는 추가적인 라이트닝 토크가 이어졌다. 테코톡에서 발표할 내용은 아니지만, 미션을 하면서 서로 가지는 질문이나 이야기하고싶은 것들을 공유하는 시간이었다. 없는 리소스를 Delete 시에 200? 204? 404? 어떤 상태코드를 내려야할지에 대한 첨예한 토론 시간도 있었다. 각자 누구에게 집중할 것인지에 따라, 철학이 조금씩 보이는 듯했다. (나라면 서비스를 통해 해결하고자 하는 중요한 도메인이라면 400을, 그렇지 않으면 204를 내어줄 듯하다! 이것도 팀 컨벤션에 맞춰서 잘 진행하면 되겠지 👀)

다음 주에는 월화목금 출근이다. 저번 주 월요일에 쉬어서 황금같은 1시 출근을 잃었는데, 이번에는 이것도 챙기고 수요일도 챙겼다 ㅋㅋㅋ 🤣 화요일부터 새로운 미션이 시작될 예정이라 화-목 리뷰 요청을 보내야 할텐데, JPA 등장이 얼마나 어려운 일이 될지 가늠이 잘 되지 않는다. 아자아자 페어랑 힘내서 빠르게 진행해야지! 관악 사람들 중에서 페어 되면 가까운 카페 잡고 수요일에 페어 하면 좋겠다.. 라는 생각도 했다 ㅎㅎ

이번 주 끝!