Post (TIL) TDD 뉴비의 Fullstack TDD 글 완성

Author: gitgitWi

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

@@ -4,9 +4,9 @@
 
 #### 3줄 요약
 
-> - ㅇㅇ
-> - ㅇㅇ
-> - ㅇㅇ
+> - 테스트 코드 뉴비로서 어디서부터 뭘 해야될 지 몰라 막막함을 느끼고, 파일럿 프로젝트 때의 안좋은 추억이 되살아났다
+> - 단순히 툴 사용법이 아니라, 테스트 코드를 작성하는 원칙이 뭔지 좀더 공부하고 정리해보고 싶다
+> - 많은 장점들이 있지만, 무엇보다 테스트 패스할 때의 소소한 즐거움이 제일 큰 장점인 듯
 
 <br />
 
@@ -32,11 +32,9 @@
 
 내가 바꾼 코드들이 제대로 동작하는지에 대해 수작업으로 확인하는 과정들이 반복됐고, 이 **단순 반복 작업들이 너무 귀찮아지면서 자연스럽게 TDD에 대한 관심으로 흘러갔다**
 
-프로젝트 구조를 모노레포로 바꿀 당시에는 줌투자 2차 오픈 일정이 빡빡하게 돌아가던 중이라, 구조 변경하랴 맵차트 개발하랴 테스트 코드를 넣을 시간이 없었지만,
+프로젝트 구조를 모노레포로 바꿀 당시에는 줌투자 2차 오픈 일정이 빡빡하게 돌아가던 중이라, 구조 변경하랴 맵차트 개발하랴 테스트 코드를 넣을 시간이 없었지만, 오픈 이후 조금 여유로워진 상황에서는 TDD 방식으로 프레임워크를 `Nest.js`로 변경할 수 있는 시간이 충분했다
 
-오픈 이후 조금 여유로워진 상황에서는 TDD 방식으로 프레임워크를 `Nest.js`로 변경할 수 있는 시간이 충분했다
-
-리팩토링 관련 책들을 읽으면서 **테스트 없는 리팩토링은 반쪽짜리 리팩토링이라는 걸 깨달았기 때문에**, 이번에는 TDD로 제대로 해봐야겠다는 각오였다
+리팩토링 관련 책들을 읽으면서 **테스트 없는 리팩토링은 반쪽짜리 리팩토링이라는 걸 깨달았기 때문에**, 이번에는 TDD를 제대로 해보면서 리팩토링을 하고싶다는 마음이 들었다
 
 문제는, 다시 한번 마주한 ***테스트 코드를 어떻게 짜야하는가에 대한 막막함***이었다
 
@@ -56,7 +54,7 @@ TDD는 `요즘 개발자(?)`라면 당연히(?) 하는 거기도 하고, 워낙
 
 파일럿 프로젝트 때 TDD에 실패했던 이유 중 하나는, 컴포넌트 단위 테스트에서 이벤트, api 요청 등 단위 테스트 범위를 벗어나는, e2e 테스트에서 해야 될 것들을 자꾸 하려고 했기 때문이다
 
-다른 하나는 테스트를 할 때 테스트 대상이 아닌 나머지 로직과 데이터를 Mock으로 만들어 제공하는 의미를 알지 못했고, 모든 걸 다 Mock으로 만들어서 제공하면 당연히 성공할 수 밖에 없는 테스트를 만드는 게 아닌가 하는 의문 때문에, 테스트 코드를 구현하는 게 의미 없다는 생각이 들었기 때문이다
+다른 하나는 테스트를 할 때 테스트 대상이 아닌 나머지 로직과 데이터를 Mock으로 만들어 제공하는 의미를 알지 못했고, 모든 걸 다 Mock으로 만들어서 제공하면 당연히 성공할 수 밖에 없는거 아닌가 하는 의문 때문에, 테스트 코드를 구현하는 게 의미 없다는 생각이 들었기 때문이다
 
 부족한 구글링 실력 탓도 있겠지만 원하는 결과는 찾기 어려웠고, 차라리 내가 좀더 공부하고 정리해서 공유하는게 낫겠다는 생각이 들었다
 
@@ -68,14 +66,13 @@ TDD는 `요즘 개발자(?)`라면 당연히(?) 하는 거기도 하고, 워낙
 
 ![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643045247027/uefVjTMZ9.png)
 
-하지만 기왕 쓰는 김에.. 회사 팀원들, 블로그, 유튜브, 강의 등 여기저기서 주워들은 내용들, 그리고 직접 테스트 코드를 구현하며 정리하게 된 **아주 간단한 원칙**은 이렇다
+하지만 기왕 쓰는 김에.. 회사 팀원들, 블로그, 유튜브, 강의 등 여기저기서 주워들은 내용들, 그리고 직접 테스트 코드를 구현하며 깨닫게 된 **아주 간단한 원칙**은 이렇다
 
 - 모든 테스트는 주어진 상황/컨텍스트(`given`)에 대해 성공 조건(`when`)-성공 결과(`then`), 실패 조건(`when`)-실패 결과(`then`)를 테스트한다
 
 - 단위 테스트는 함수/클래스 내부 동작이 잘 동작하는지를 테스트하기 때문에, 당연히 나머지 외부에 대해서는 정상 동작한다고 가정한다
-  - Mock 함수, 데이터를 잘 만들어야 하는 이유
-  - 이 때문에 그다지 효율적이진 않을 수 있다
-  - 새로운 기능 개발하는 경우, 좀더 꼼꼼하게 구현할 필요가 있는 경우
+  - Mock 함수, 데이터를 잘 만들어야 하는 이유 👉 이 때문에 그다지 효율적이진 않을 수 있다
+  - 새로운 기능 개발하는 경우엔, Mock 함수/데이터를 만들면서 인터페이스나 추상클래스를 만들수 있기 때문에 설계 측면에선 괜찮을 듯
 
 ![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643046228793/CjJWMTHL1.png)
 
@@ -84,9 +81,18 @@ TDD는 `요즘 개발자(?)`라면 당연히(?) 하는 거기도 하고, 워낙
   - 실제 데이터, api를 가지고 테스트할 수 있음; mock 데이터/함수도 당연히 사용 가능
   - 리팩토링 등 이미 구현된 기능에 대해 코드 변경이 있는 경우
 
-## ??
+<br />
+
+## 10년 만에 느껴보는 수학 문제집 푸는 맛(?)
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643101897718/aeW-AlUHM.png)
+
+> *VSCode, IntelliJ 등 에디터에서 테스트 관련 설정을 하면, 굳이 테스트 관련 명령을 하지 않아도 알아서 코드 수정을 반영해 테스트를 실행해준다*
+
+테스트 코드의 장점은 누구나 알다시피, 코드 변경을 하더라도 기능이 잘 작동하는지를 빠르게 확인할 수 있다는 점이다
 
-![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643044538781/8K9QAXJI8.png)
+그것말고도 개인적으로 꽤 괜찮은 side-effect를 느낀 부분은 ***개발자로서 자기 효능감을 느낄 수 있다***는 점이다
 
-지난 회고에서도 언급했던 것처럼, e2e 테스트 커버리지 90% 정도로 `Koa.js` -> `Nest.js` 프레임워크 변경을 잘 마무리할 수 있었다
+학창 시절 수학 문제집을 풀고 채점할 때, 동그라미가 하나씩 늘어날때마다 기분이 좋았던 기억이 있는데, 깔끔하게 통과한 테스트 결과를 보면 왠지 상쾌하고 기분이 좋아지는 듯 하다
 
+개발은 공부하면 할수록 스스로 부족하다고 느낄 때도 많지만, 이렇게 사소하게나마 *`내가 만든 코드가 테스트를 통과했구나`*하는 즐거움을 주는 게 가장 큰 장점이 아닐까 생각이 든다