Post (TIL/draft) TDD 뉴비의 Fullstack TDD 내용추가

Author: gitgitWi

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

@@ -1,30 +1,30 @@
-# TDD 뉴비의 Full-stack(?) TDD
+# TDD 뉴비가 느낀 러닝 커브와 재미
 
-- 주간회고 02. TDD 뉴비가 느낀 러닝 커브와 재미
-- '22.01.24.
-
-<br />
+- 주간회고 02. TDD 뉴비의 Full-stack(?) TDD 1편
 
 #### 3줄 요약
 
 > - ㅇㅇ
 > - ㅇㅇ
 > - ㅇㅇ
 
+<br />
+
 ---
 
-## 테스트 코드 앞에만 서면 나는 왜 작아지는가~
+## 테스트 코드 앞에만 서면~ 나는 왜 작아지는가~
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643041008094/t76_KRs7T.png)
 
-![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643039491078/MOPkQjLtQ.png)
+> _지금 보니, 약간 망했다는 얘기를 굉장히 구구절절 쓴 것 같다..._
 
 작년 수습기간 파일럿 프로젝트(`investing.com` 클론, [👉 파일럿 프로젝트 회고](https://zuminternet.github.io/zum-front-investing-clone/)) 초반에 여러가지로 시간을 많이 날렸지만, 그중에서도 가장 허탕을 쳤던 것 중 하나는 TDD로 개발을 해본답시고 1주일을 날린 것이다
 
 1년 반이라는 예상보다 길고 힘들었던 커리어 전환 기간을 거치고 취업한 상태여서 너무 신이 났었는지, ***이것도 해보겠다 저것도 해보겠다 너무 욕심이 많았던*** 것 같기도 하다
 
 `Vue.js`도 처음해보는데 `TDD`를 해보겠다하고, 데이터 업데이트를 실시간으로 해보겠다고 `SSE`를 도입하고, 몇번 써보지도 않은 `MongoDB`에 잘 맞지도 않는 `TypeORM`을 억지로 끼워넣느라 많지도 않은 시간을 삽질하는데 써버렸고, 결국 중간발표까지 요구사항 절반도 못하게 되는 대참사가 벌어졌다
 
-
-그나마 `SSE`, `TypeORM`은 어떻게든 됐고, `아 이렇게 하는거 아니구나` 하는 걸 깨닫기도 했지만, `Frontend TDD`는 결국 시간만 쓰고 혼란스러움만 남긴 채 접게 됐다
+그나마 `SSE`, `TypeORM`은 어떻게든 됐고, `아 이렇게 하는거 아니구나` 하는 걸 깨닫기도 했지만, ***`Frontend TDD`는 결국 시간만 쓰고 혼란스러움만 남긴 채 접게 됐다***
 
 <br />
 
@@ -36,18 +36,57 @@
 
 오픈 이후 조금 여유로워진 상황에서는 TDD 방식으로 프레임워크를 `Nest.js`로 변경할 수 있는 시간이 충분했다
 
-문제는 ***테스트 코드를 어떻게 짜야하는가에 대한 막막함***이었다
+리팩토링 관련 책들을 읽으면서 **테스트 없는 리팩토링은 반쪽짜리 리팩토링이라는 걸 깨달았기 때문에**, 이번에는 TDD로 제대로 해봐야겠다는 각오였다
 
+문제는, 다시 한번 마주한 ***테스트 코드를 어떻게 짜야하는가에 대한 막막함***이었다
 
 <br />
 
-## 지금 당장 TDD 하고 싶은데, 뭘 어떻게 해야 하지..???
+## 지금 당장 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 함수, 데이터를 잘 만들어야 하는 이유
+  - 이 때문에 그다지 효율적이진 않을 수 있다
+  - 새로운 기능 개발하는 경우, 좀더 꼼꼼하게 구현할 필요가 있는 경우
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643046228793/CjJWMTHL1.png)
+
+- e2e/통합 테스트는 내부 동작보다는 함수/클래스 등 전반적인 기능을 테스트할 수 있다
+  - 말그대로 end-to-end, 사용자 input에 따른 output이 어떻게 나오는지를 테스트
+  - 실제 데이터, api를 가지고 테스트할 수 있음; mock 데이터/함수도 당연히 사용 가능
+  - 리팩토링 등 이미 구현된 기능에 대해 코드 변경이 있는 경우
+
+## ??
+
+![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1643044538781/8K9QAXJI8.png)
 
+지난 회고에서도 언급했던 것처럼, e2e 테스트 커버리지 90% 정도로 `Koa.js` -> `Nest.js` 프레임워크 변경을 잘 마무리할 수 있었다
 
-<br />