코드스테이츠 Advanced Web H.A 회고

마지막 H.A(Advanced Web)

벌써 코드테이츠에서의 4달이 흘러간다.

그동안 많은 것들을 배웠다

기본적인 자바스크립트 변수 할당에서부터, 현재 AWS로 웹앱, 서버, 데이터베이스까지 배포하는 것까지 배움으로서 기본적인 교육과정은 끝이 났다. 이제 우리에게 남은 것은 📱💻 프로젝트!!

이제까지 Immersive 프로그램 동안 2번의 H.A, 쉽게 말하면 과정을 잘하고있는지에 자기 점검 같은 테스트가 있고 마지막 이 Advanced Web H.A는 이제 까지 코드스테이츠에서 배운 과정을 총 망라해서 주어진 요구대로 DB스키마 제작, 프론트단 웹앱의 버그해결, 기능추가, 서버와의 연결, 결국 DB에 정보를 저장, 이용할 수 있는 간단한 프로그램을 만드는 일이었는데, 교육과정을 잘 따라오고있었다면 또 열심히 했다면 큰 무리없이 풀 수 있는 문제들이었다.

이 테스트에서 중요한 것은 1. 모든 테스트케이스 통과 2. 서비스가 실제로 구현이 되야 함.

가끔 교육과정 중에 스프린트 과제를 진행하다보면 테스트케이스는 통과하는데 서비스 구현이 안되거나, 반대로 서비스 구현은 되는데 테스트케이스 통과는 안되거나 둘 중 하나의 상황을 맞이할 수도 있는데, 이 테스트도 지난 과제들과 마찬가지로 테스트통과, 서비스 구현이 통과 컷트라인이었다.

하지만 나에게는 큰 어려움이 있었으니, 결론부터 이야기하면, 서비스 구현이 잘 되서 잘 돌아가는데, 어떤 테스트케이스들이 도저히 통과하지 않는 것이었다.

그것은 다름이 아니고

React의 Click Method들이 작동을 잘해서 서버로 요청도 잘보내고, response도 잘 받아서 React App에서 잘 뿌려주고 하는데, 테스트케이스에서는 동작하지 않았다고 나오는 것이었다.

사람이 긴장을 하면서 이런 상황을 맞이하니까 보이던 것도 안보였더랬죠..

사람은 경험으로 배운다고 한다더니, 이 전에도 비슷한 상황들이 이었기에 바로 테스트케이스부터 보고 내 리액트 콤포넌트의 calssName과 Enzyme테스트케이스의 wrapper.find()메소드가 찾는 엘레멘트를 비교했고(이 덕분에 wrapper.find()가 엘레멘트를 찾는 방식을 이해했다는 것은 고생끝에는 낙이온다는 것을 느끼게 해준 부분... ...뭐? 어쨌든 jest, mocha/jasmin, chai같은 테스트 케이스들의 차이점에대해 약간은 더 알아갔던 것 같다.)

아니나 다를까 떡하니 다른 className을 찾고있는 테스트케이스를 바라보며 "옳거니!" 했지만 아무리 이름을 맞춰서 바꾸어 보아도, 나오는 메세지는 메소드가 사용되지 않았다는 오류 메세지 뿐...!

대체 왜... 작동은 잘 된단 말이에요!!

결국 내가 썼던 방법들을 나열 해보면,

1. 리액트 콤포넌트 클래스 이름 바꾸기
2. 테스트케이스에서 콘솔로그로 어떤 정보가 들어오고 나가는지 확인하기
3. VSCODE debugger로 테스트케이스 자체를 디버깅하면서 대체 wrapper.find()가 내 className을 어떻게 찾는지, 메소드를 실행시키는지 따라가 보기.

3번방법은 클릭매소드 하나찾는데 클릭, 클릭, 클릭을 하면서 가다보니 한시간은 넘게 따라간 것 같다. 로직 안에 이 파일, 저 파일을 왔다 갔다하며, 또 때로는 반복문, map을 사용하는 함수들을 지나며 가다보니 시간이 엄청 걸린 것 같다.

클릭 한번에 일어나는 일들이 이렇게 복잡하다니 놀라웠을 다름이었다.

사실 이 때 이미, 나는 정답을 봤다. 답을 다 안 뒤에야 눈치채기는 했지만.

결론부터 얘기하면, 문제는 로직이 아니라 서버 통신 방식에 있었다.

나는 클라이언트와 서버 로직을 HTTPS로 작성하였고, 그래서 서버, 클라이언트간 통신 및 서비스 구현은 잘 되었는데, 정작 테스트케이스에서는 HTTP통신으로 테스트 하였고, 그래서 작동은 되지만 테스트케이스에 걸리는 작동은 아니였던 것이었다.

하..

사실 코드스테이츠에서 힌트 아닌 힌트를 하나 줬었는데, 코드를 갔다 써 놓을 수는 없으니, 예를 들면 express를 이용해서 const app = express(), app.listen()으로 연결을 이미 해놓았었다. 나는 이걸 구지https.createServer()로 다시 만들어서 클라이언트와 통신했다.
사실 이 부분부터 테스트 케이스와의 긴, 긴 여정이 시작된 것이었다.

내가 처음부터 const app = express(), app.listen()은 당연히 HTTP라는 것을 알고 있었다면 진작에 알아 챘을 수도 있었을 것이다.

결론부터 얘기하자면, 모든 통신을 http로 바꾼 다음에는 바로 테스트케이스가 통과되기 시작했고,
그 이후에 발견된 다른 오류들은 다 className이 다르거나, 콤포넌트안의 내용이 다르거나 했던 것들이라 차근차근 잡을 수 있었다.

아까 말한 테스트케이스를 디버깅하면서 정답을 발견했었다는 것은 뭐였냐면

테스트케이스 디버깅을 하면서, 테스트케이스가 어떤 문자열을 조합하는 것을 발견하였고, 그것이 결국 HTTP통신 방식을 만드는 과정이었는데 여기서 HTTP를 본 것 같았다. HTTP와 HTTPS의 차이점을 알고 있다지만, 어쩌면 그것을 보고 "내가 쓴건 HTTPS인데, 여기는 HTTP네"하고 느끼지 못했다는 것은

1. 내가 뭘 썼는지에 대한 정확한 이해부족
2. 기본을 다지는 실력
3. 집중력

등이 있었던 것 같다.

사실 HTTP & HTTPS 통신 관련 공부가 부족했던 것을 인정한다.

이 테스트를 통해 느낀 점

1. "테스트 케이스가 그렇게 중요한가?" 라고 테스트케이스가 통과되지 않을 때면 생각했을 때도 있었다 그런데 지금은 "중요하다"라고 생각하고 있다. 왜냐면, 어떤 팀에 가서 일을 하게 될지 모르겠지만 테스트를 만들면서 개발을 진행해가는 팀에 가게 된다면 결국 서로 합의하에 만들어진 규격, 규칙을 지키면서 개발을 해 나가야 할 텐데, 그럴거면 소스코드 및 테스트 케이스 코드를 잘 읽을 수 있는 능력이 꼭 필요하다고 느꼈다.
   그리고 결정적으로 얼마전 NAVER에서 주최한 DEVIEW 2020 온라인 컨퍼런스에 참여하여 몇몇 발표를 접할 기회가 있었는데, 거기서 중간에 나오는 NAVER LABS소개 영상에서 똑같이 테스트를 만들고 개발을 진행해 나가는 모습을 보게 되었다. 그러면서 테스트를 만들 수 있고, 개발하고자 하는 목적에 맞게 그것을 이용할 수 있는 능력도 필요할 수 있겠구나 생각하게 됐다.

2. 기본만 잘알아도, 코드는 읽을 수 있다. 새로 배우는 개념들, 생소한 것들이 있겠지만, 가장 익숙해 질 수 있는, 어쩌면 또 가장 빨리 배울수 있는 길은 결국은 기본이 탄탄하면 그 위에 뭐가 올라가도 이해할수 있는게 아주 많다는 것도 알게 되었다. 그래서 "어떻게 쓰느냐"도 매우 중요하지만, "왜 이걸 쓰고, 이걸 쓰면 어떻게 코드안에서 역할을 하는지"에 대해 알아가는 것도 너무 중요하다는 것을 깨닫는 시간이었다.

"모호한 지식"은 또 다른 "불확실"이라는 가지를 만들어 낼 수 있기에..!

앞으로 프로젝트가 남았다. 서비스를 구현한다니 너무 신나고 기대되고 또 살짝 걱정이 되기도 한다. 잘 할 수 있겠지?

화이팅 달려나가보자! 🛫