Merge pull request #20 from gitgitWi/nextjs/v1

Author: gitgitWi

pages/posts/til/tdd/fullstack-tdd-by-newbie.md

@@ -0,0 +1,98 @@
+# TDD 뉴비가 느낀 러닝 커브와 재미
+
+- 주간회고 02. TDD 뉴비의 Full-stack(?) TDD 1편
+
+#### 3줄 요약
+
+> - 테스트 코드 뉴비로서 어디서부터 뭘 해야될 지 몰라 막막함을 느끼고, 파일럿 프로젝트 때의 안좋은 추억이 되살아났다
+> - 단순히 툴 사용법이 아니라, 테스트 코드를 작성하는 원칙이 뭔지 좀더 공부하고 정리해보고 싶다
+> - 많은 장점들이 있지만, 무엇보다 테스트 패스할 때의 소소한 즐거움이 제일 큰 장점인 듯
+
+<br />
+
+---
+
+## 테스트 코드 앞에만 서면~ 나는 왜 작아지는가~
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643041008094/t76_KRs7T.png)
+
+> _지금 보니, 약간 망했다는 얘기를 굉장히 구구절절 쓴 것 같다..._
+
+작년 수습기간 파일럿 프로젝트(`investing.com` 클론, [👉 파일럿 프로젝트 회고](https://zuminternet.github.io/zum-front-investing-clone/)) 초반에 여러가지로 시간을 많이 날렸지만, 그중에서도 가장 허탕을 쳤던 것 중 하나는 TDD로 개발을 해본답시고 1주일을 날린 것이다
+
+1년 반이라는 예상보다 길고 힘들었던 커리어 전환 기간을 거치고 취업한 상태여서 너무 신이 났었는지, ***이것도 해보겠다 저것도 해보겠다 너무 욕심이 많았던*** 것 같기도 하다
+
+`Vue.js`도 처음해보는데 `TDD`를 해보겠다하고, 데이터 업데이트를 실시간으로 해보겠다고 `SSE`를 도입하고, 몇번 써보지도 않은 `MongoDB`에 잘 맞지도 않는 `TypeORM`을 억지로 끼워넣느라 많지도 않은 시간을 삽질하는데 써버렸고, 결국 중간발표까지 요구사항 절반도 못하게 되는 대참사가 벌어졌다
+
+그나마 `SSE`, `TypeORM`은 어떻게든 됐고, `아 이렇게 하는거 아니구나` 하는 걸 깨닫기도 했지만, ***`Frontend TDD`는 결국 시간만 쓰고 혼란스러움만 남긴 채 접게 됐다***
+
+<br />
+
+그렇게 약 5개월의 시간이 지나고, 차트 서버를 담당하게 되면서 모놀리식 구조에서 모노레포 구조로 바꾸고, 프레임워크를 `Koa.js`에서 `Nest.js`로 변경하는 대공사를 벌이게 된다
+
+내가 바꾼 코드들이 제대로 동작하는지에 대해 수작업으로 확인하는 과정들이 반복됐고, 이 **단순 반복 작업들이 너무 귀찮아지면서 자연스럽게 TDD에 대한 관심으로 흘러갔다**
+
+프로젝트 구조를 모노레포로 바꿀 당시에는 줌투자 2차 오픈 일정이 빡빡하게 돌아가던 중이라, 구조 변경하랴 맵차트 개발하랴 테스트 코드를 넣을 시간이 없었지만, 오픈 이후 조금 여유로워진 상황에서는 TDD 방식으로 프레임워크를 `Nest.js`로 변경할 수 있는 시간이 충분했다
+
+리팩토링 관련 책들을 읽으면서 **테스트 없는 리팩토링은 반쪽짜리 리팩토링이라는 걸 깨달았기 때문에**, 이번에는 TDD를 제대로 해보면서 리팩토링을 하고싶다는 마음이 들었다
+
+문제는, 다시 한번 마주한 ***테스트 코드를 어떻게 짜야하는가에 대한 막막함***이었다
+
+<br />
+
+## 지금 당장 TDD 하고 싶은데, 뭘 어떻게 해야 할까..???
+
+TDD는 `요즘 개발자(?)`라면 당연히(?) 하는 거기도 하고, 워낙 많은 테스트 관련 책과 강의, 블로그, 아티클들이 있기 때문에 공부를 한다면 충분히 할 수 있는 분야인 것 같다
+
+하지만 **당장 프로젝트에 적용해보려고 구글링해보면, 생각보다 볼만한 것들이 많지 않았던 것 같다**
+
+물론 JS 테스트 코드를 짜려고 하면 언제나 나오는 `Jest` 사용법 정도는, 정말 너무 많다 싶을 정도로 자료가 많다
+
+  > *이런 라이브러리나 툴 사용법은 필요할 때마다 그때그때 공식문서 위주로 찾아보고, StackOverflow 검색해보고, 그래도 뭔가 부족하다 싶으면 `GitHub`이나 [SourceGraph](https://sourcegraph.com/search), [tabnine](https://www.tabnine.com/code) 오픈 소스 코드 검색으로 예제를 찾아보면 꽤 괜찮은 내용들이 많다*
+
+그러나 당장 프로젝트에 적용하기 위해 찾아보고 싶었던 주제는 이런 툴 사용법이 아닌, ***단위 테스트에선 무엇을 어떻게 테스트해야 하는가, Controller를 테스트하는데 MockService는 왜 만들어야하나 등 원리원칙적인 내용들을 찾고 싶었다***
+
+파일럿 프로젝트 때 TDD에 실패했던 이유 중 하나는, 컴포넌트 단위 테스트에서 이벤트, api 요청 등 단위 테스트 범위를 벗어나는, e2e 테스트에서 해야 될 것들을 자꾸 하려고 했기 때문이다
+
+다른 하나는 테스트를 할 때 테스트 대상이 아닌 나머지 로직과 데이터를 Mock으로 만들어 제공하는 의미를 알지 못했고, 모든 걸 다 Mock으로 만들어서 제공하면 당연히 성공할 수 밖에 없는거 아닌가 하는 의문 때문에, 테스트 코드를 구현하는 게 의미 없다는 생각이 들었기 때문이다
+
+부족한 구글링 실력 탓도 있겠지만 원하는 결과는 찾기 어려웠고, 차라리 내가 좀더 공부하고 정리해서 공유하는게 낫겠다는 생각이 들었다
+
+올해 안으로 가이드라인을 정리해서, GitBook 이나 간단한 웹으로 만들어 공유해 볼 예정이다
+
+<br />
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643045178911/CJd3G_5f3.png)
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643045247027/uefVjTMZ9.png)
+
+하지만 기왕 쓰는 김에.. 회사 팀원들, 블로그, 유튜브, 강의 등 여기저기서 주워들은 내용들, 그리고 직접 테스트 코드를 구현하며 깨닫게 된 **아주 간단한 원칙**은 이렇다
+
+- 모든 테스트는 주어진 상황/컨텍스트(`given`)에 대해 성공 조건(`when`)-성공 결과(`then`), 실패 조건(`when`)-실패 결과(`then`)를 테스트한다
+
+- 단위 테스트는 함수/클래스 내부 동작이 잘 동작하는지를 테스트하기 때문에, 당연히 나머지 외부에 대해서는 정상 동작한다고 가정한다
+  - Mock 함수, 데이터를 잘 만들어야 하는 이유 👉 이 때문에 그다지 효율적이진 않을 수 있다
+  - 새로운 기능 개발하는 경우엔, Mock 함수/데이터를 만들면서 인터페이스나 추상클래스를 만들수 있기 때문에 설계 측면에선 괜찮을 듯
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643046228793/CjJWMTHL1.png)
+
+- e2e/통합 테스트는 내부 동작보다는 함수/클래스 등 전반적인 기능을 테스트할 수 있다
+  - 말그대로 end-to-end, 사용자 input에 따른 output이 어떻게 나오는지를 테스트
+  - 실제 데이터, api를 가지고 테스트할 수 있음; mock 데이터/함수도 당연히 사용 가능
+  - 리팩토링 등 이미 구현된 기능에 대해 코드 변경이 있는 경우
+
+<br />
+
+## 10년 만에 느껴보는 수학 문제집 푸는 맛(?)
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643101897718/aeW-AlUHM.png)
+
+> *VSCode, IntelliJ 등 에디터에서 테스트 관련 설정을 하면, 굳이 테스트 관련 명령을 하지 않아도 알아서 코드 수정을 반영해 테스트를 실행해준다*
+
+테스트 코드의 장점은 누구나 알다시피, 코드 변경을 하더라도 기능이 잘 작동하는지를 빠르게 확인할 수 있다는 점이다
+
+그것말고도 개인적으로 꽤 괜찮은 side-effect를 느낀 부분은 ***개발자로서 자기 효능감을 느낄 수 있다***는 점이다
+
+학창 시절 수학 문제집을 풀고 채점할 때, 동그라미가 하나씩 늘어날때마다 기분이 좋았던 기억이 있는데, 깔끔하게 통과한 테스트 결과를 보면 왠지 상쾌하고 기분이 좋아지는 듯 하다
+
+개발은 공부하면 할수록 스스로 부족하다고 느낄 때도 많지만, 이렇게 사소하게나마 *`내가 만든 코드가 테스트를 통과했구나`*하는 즐거움을 주는 게 가장 큰 장점이 아닐까 생각이 든다