코드숨 React 5기 - 5주차 회고

5주차 주간 회고

Facts

• 코드숨 5주차 과제 수행
  • 레스토랑 조회 구현하기

Feelings

• 과제 첫 테스트 작성 시에, 테스트 내용에 redux에 대한 mock이 포함되어 있었다. 그런데 이렇게 작성을 하다보니 mock을 한 redux 초기 상태를 어디에 위치시켜야 할지 혼동이 왔다. 이에 대해 처음부터 redux에 대한 mock을 추가하지 말고 먼저 컴포넌트가 제공해야 하는 기능들을 가장 쉽고 빠르게 작성한 뒤에 green을 통과 하고 나서 mock이 필요한 부분을 찾아서 mock을 추가해야 한다는 피드백을 받았다. 피드백 대로 redux에 대한 mock을 다 지우고 화면을 그리고 기능을 만족하도록 빠르게 작성하고 리팩터링을 하는 방식으로 진행을 했더니 테스트 작성과 코드 구현이 처음보다 수월하게 진행되었다. 처음부터 redux를 넣으려고 했던 것은 여러 단계를 뛰어 넘고 진행하려는 욕심때문이었는데, 다소 지루하더라도 쉽고 빠른 구현 이후에 리팩토링하는 방식으로 진행해야 겠다고 생각했다.

• redux thunk의 경우에는 테스트를 어떻게 작성해야 할 지 고민이었다. api 통신 부분을 mocking하고 이후에 mocking한 데이터 결과를 action으로 잘 넘기는 지를 테스트 해야하는 지 고민했는데, 결과적으로 나는 테스트를 통해 어떤 피드백을 받기를 원하는가?가 항상 어려운 지점이라는 것을 느꼈다. fetch에 대한 mocking을 어떻게 하는지 글을 찾아보다가 이 글을 읽게 되었는데, 많은 부분을 이해하지 못했지만 중요한 지점이라고 생각한 것은 그 테스트가 실제로 나에게 무엇을 보장해 주는지를 생각하고 테스트를 작성하는 가?라는 질문이었다. 아직 thunk 테스트에서 무엇을 확인해야 할지 감이 잘 잡히지 않았다. 결론적으로 redux thunk 관련된 테스트 작성은 과제 풀이의 도움을 받아야 겠다고 생각했다.

• 3주차 과제 피드백에서 beforeAll, beforeEach등으로 안전한 테스트를 제공할 수 있다는 내용이 있었는데, 테스트 관련 자료들을 읽으면서 테스트 작성 시에, 특히 mock을 구성할 때 앞서서 작성한 mock이 다른 테스트에 영향을 미칠 수 있는 지점에 대해서도 고려를 해야된다는 것을 알게 되었다. 역시 피드백 내용은 그냥 한귀로 흘리면 안된다는 것을 느꼈다…(잘 몰라서 중요한 걸 들어도 놓치는 것 같다…)

Findings

• 지루하더라도 컴포넌트가 제공해야 할 최소한의 기능 명세와 빠르고 쉬운 구현, 이후에 리팩토링을 해야한다.

• 테스트를 통해 어떤 피드백을 받고 싶은 지 생각하면서 테스트 작성해야 한다. 기계적으로 아무 생각없이 이전에 작성했던 테스트 코드를 다시 작성하면 안된다.

• 테스트에 mock이 자주 등장하는 데, mock이 테스트 할 때 왜 필요한지 몰랐다. 이 글을 읽은 덕분에 mock의 목적이 독립적인 단위 테스트 구성을 위한 것임을 알게되었다. 상황에 따라 참이 되거나 거짓이 되는 테스트는 우리에게 아무 것도 보장해주지 않기 때문에, 테스트 결과를 신뢰하기 위해서는 단위 테스트는 항상 동일한 실행 결과를 보장해야 한다. 그러나 다른 함수에 의존하는 함수의 경우에는 의존하는 함수가 항상 같은 결과를 주지 않는 경우(예. fetch response) 테스트 결과는 항상 같은 결과를 보장할 수 없다. 따라서 의존하는 함수나 객체를 흉내내는 함수나 객체가 필요하고 해당 함수나 객체를 test double이라고 부른다는 것을 알게 되었다. test double은 많이 들어봤고, spy, stub… 각각의 차이들도 읽어봤는데 근본적으로 해당 test double들이 어떤 맥락에서 사용이 필요한지를 알게 되었다.(아주 조금 알게 되었다. 언제나 그렇듯 갈길이 멀다…)

• 각각의 테스트가 독립적으로 동작하는 지 고려하고 작성해야 할 필요성

Affirmation

• 좀 더 생각하면서 테스트를 작성하고, 욕심부리지 않고 tdd로 과제를 수행하기

• thunk에 대한 test와 fetch mocking에 대한 내용 정리하기