주간회고 [12/13] - [12/19]

배운점

• Jest / testing-library

  • describe - context - it
    • 서술적인 테스트 시나리오를 적어야하한다.
    • describe은 테스트 주체가 되는 서술대상이다.
    • context는 따로 비교해줘야할 맥락있을 때 선택적으로 쓴다.
    • it은 실제 테스트하는내용이다.
  • test는 간단한 단독 테스트 작성시 사용한다.
  • Red Green Refactoring 순서가 되게끔 jest를 작성하고 코딩을 작성하면서 천천히 쌓아올라가면 된다.
  • dom을 선택할 수있는 방법은 여러가지이다. 가장 이해하기 편한걸로 사용하자
  • render함수는 다음 처럼 재사용을 할 수 있다.
    • const renderList = () =>render(())
  • 테스트 할 때 정해진 컴포넌트만 한다. 다른 컴포넌트를 쓰지 않는다.

• 가독성

  • 작동하는 것은 기본이다. 변수명부터 위치까지 읽기 편하도록 작성해야한다. 테스트 코드 작성보다는 refactor 커밋이 더 많았어서 앞으로 더 신경써서 작성해야겠다.
  • 최대한 중복을 줄이자/ 핵심만 작성하자

느낀점

• Jest
  • 신세계였다. 말로만 듣던 TDD를 직접 해보니 경쟁력이 생기는 기분이었다. 왜 다들 TDD를 외치는지 이해하는 클래스였다. 이렇게 짜면 나중에 고치기도 쉽고 이해하기도 쉽다.
• 멘붕
  • 나는 내 능력 안에서 최선을 다한 것같지만 매우 많이 찜찜했다. 여기저기 둘러보다가 지난 과거 pull&request를 볼 수 있었다. 나는 충격을 먹었다. 다들 질문퀄리티와 코딩 퀄리티가 너무 높았다. 나는 내 나름대로 주어진 문제를 해석해서 코딩을 했는데 그 결과가 비교하기에도 부끄럽게 느꼈다.
  • 나는 왜 질문이 적을까? 왜 이 사람은 이렇게 코딩을 했을까? 왜 나는 저렇게 생각못했을까? 왜 나는 시키는 것만 할까? 이런 생각들이 머릿속에 맴돌았다. 답하기 힘든 질문들이었다.
  • 원래 하나를 알려주면 열을 알도록 응용해서 발전시켜야하는데 하나를 알려주면 나에게는 그 하나 자체로 만족이 되었다.
  • 피드백을 반영할때마다 드는 생각이 있다. ‘리뷰어분들의 의견을 따르니 코드가 보기가 좋구나’ 근데 거기서 끝이다. 그래서 리뷰를 반영할 때마다 마음이 불편하다.
  • ‘아니 이보다더 어떻게 발전시키지?’ ‘이거는 그냥 받아들여야하는거 아닌가?’ 라는 생각보다 좀더 효율적인 것을 찾아보자
  • 내가 뭔가 잘못됐다고는 느끼는데 어떻게 고쳐야할지 잘 모르겠다.
  • 이런 나의 부족함이 점점 더 쌓여서 갭을 만들까 두렵다.

To-do 테스트 작성하기 코드리뷰
https://github.com/CodeSoom/react-week3-assignment-1/pull/99