왜(22.11.01TIL)

인출을 하다가 컴포넌트만 테스트하는게 보여서 기존과 테스트 방식이 좀 다르게 느껴졌다. 강의에서 나온 내용이니 프론트엔드는 원래 컴포넌트만 테스트하나보다~ 라고 생각을 했다. 혹시몰라서 질문 게시판에 여쭤보았는데 내가 잘못 생각하는 부분을 짚고 넘어갈 수 있었다.

답변

홀맨님과 아샬님께서 해주신 답변은 당연히 비즈니스 로직을 테스트해야된다였다. 이번주차에서 하고있는 내용은 스프링으로 치자면 WebMVC 테스트에서 MockMVC부분이라고 생각하면 되는데, 한마디로 모킹에 관련된 강의 내용이라고 보면 된다. 비즈니스 로직을 제대로 테스트하기 위해 부수적인 수단을 배우는 주간이라고 생각하면 된다. 테스트는 항상 핵심 부분인 비즈니스 로직을 우선적으로 테스트 해야하고, 핵심적인 부분으로 내려갈수록 프레임워크들의 흔적을 찾아볼 수 없게 순수한 코드를 사용하게 된다. 추가로 아샬님께서 테스트에 대한 이해를 돕기위해 영상을 하나더 올려주셨다.

홀맨님의 FEConF

리덕스 아키텍처에서 발생하는 거대한 단일 스토어를 어떻게 작은 마이크로 스토어로 만들 것인가?를 주제로 저번에 홀맨님이 하신 강연을 다시 돌려보았다. 일단 주제에서부터 컴포넌트보다 비즈니스 로직(스토어)의 중요성이 느껴진다. 실제 강연에서도 컴포넌트의 테스트는 하나도 없고, 도메인모델과 스토어에 관한 비즈니스 로직 테스트만 진행한다. 프론트엔드 역시 TDD의 메인 타겟은 비즈니스 로직인 것을 확인할 수 있었다.

돌아보기

메가테라에 들어온후 TDD를 처음 배운 주차부터 지금까지 아샬님이 줄곧 강조하신 내용이 떠올랐다. 입력과 출력은 이미 누군가가 잘 만들어 놓았으니 우리는 처리부분(비즈니스 로직)만 잘 짜면 된다고. TDD를 10주 넘게 했음에도 TDD의 핵심적인 부분을 잊고 이런 질문을 한게 좀 부끄러웠다. 계속해서 왜?를 던지면서 공부를 해야 하는데 관성적으로 학습한게 아닌가 반성을 해야 할것같다. 사실 이번 주차의 주제인 플럭스 아키텍처도 왜쓰는지 물어보면 자신있게 답하지 못할 것 같다. 내일은 플럭스의 멘탈 모델을 다시한번 복습해야겠다.

액션플랜

1. 플럭스 아키텍처 멘탈모델 다시 정리하기 (왜 쓰는가?에 대답할 수 있어야 함)