리액트 3주차 회고

한 것

• 이미 만들어진 Todo App에 테스트코드 작성해보기

느낀것

• 기다리고 기다리던 테스트코드에 대해 배우고 사용해보게되었다. 처음에는 무엇을 어떻게 얼만큼 테스트해야할지 감이 잡히지 않아 헤매었지만 트레이너님께서 코드리뷰를 통해 계속해서 피드포워드를 주시면서 방향을 잡아주신덕에 점점 어떤식으로 해야할지 느낌을 찾을 수 있었다.
• 과제를 처음 시작했을때는 각각의 하위 컴포넌트에서 자신들이 가진 기능에 대해 테스트를 하고 이러한 자식 컴포넌트를 가지고있는 상위 컴포넌트에서 또 테스트를 하게되면 자식 컴포넌트에서 했던 테스트를 다시 하게되므로 중복되는 테스트가 아닌가 하는 의문을 가지고 시작했었다. 하지만 마지막에 App 컴포넌트 테스트를 하면서 아.. 트레이너님이 왜 관심사를 강조하셨는지, 관심사에 따라 테스트도 달라지므로 중복되는 것이 아니라고 하셨는지, 왜 E2E테스트와 유사하게 작성된다고 하셨는지, 동작하는 부분을 테스트하라는 것인지에 대해 알게되었다...ㅎㅎㅎㅎㅎ
• 자식컴포넌트는 당연히 상태값에 대해 알수가 없는데 mock function을 넣어놓고 상태값이 바뀌기만을 기다리며 리렌더링된 화면을 테스트해주려 매우 노력하고 있는 바보같은 나를 발견할 수 있었다 하하
• 테스트 시나리오 작성이 너무 어려웠다.. 영어를 잘 못해서 처음에는 구글 번역기에 한국어로 쳐서 변역해온 문장을 가져왔는데 굉장히 단순하게 처리할 수 있는 시나리오가 너무나 복잡하게 바껴버렸다. 다행히 트레이너님이 피드포워드를 주셔서 어떤식으로 작성하면 될지 아주 조금 감을 잡은 것 같다. 감사합니다!!!

배운것

1. 자식 컴포넌트는 단순히 상위 컴포넌트에서 이벤트 핸들러 함수를 전달 받아 호출하고 상태값을 전달 받아 화면에 그리는것이 관심사이다. 그래서 클릭 이벤트가 발생했을때 클릭 이벤트를 호출하는 역할만하고, 외부에서 어떻게 구현이 되어있고 어떤 로직으로 작동하는지 알 수가 없다. 그러므로 무언가를 전달받아 그리기만하는 자식 컴포넌트에서는 그저 이벤트가 발생했을때 함수가 호출되었는지, 상태값을 받아서 화면에 그리는지만 테스트해주면 된다. 상태값이 어떻게 변화하는지는 관심사가 아니므로 테스트할 필요가 없다.
2. 테스트 케이스를 작성할때, describe ~ context(상황이 나뉘어지는 경우에만 사용) ~ it 구조를 많이 사용한다.
   • describe는 테스트하려는 대상을 서술
   • context는 when, with, without만을 사용해 상황(맥락)을 서술
   • it은 테스트 내용을 서술
3. 테스트 파일에서 describe가 여러개가 될 수도 있기때문에 각 describe에서 사용하는 변수와 함수는 해당하는 describe 내부에서 선언해주는게 좋다
4. context를 사용했을때는 대비되는 상황에는 무엇을 테스트해주고 싶은지를 생각해보자, 반대의 상황을 테스트할 필요가 없다면 context를 사용하지 말자. it을 사용하자.
5. 테스트 시나리오를 작성할때 테스트를 통해 확인하고 싶은게 무엇인지에 대해 생각해보자. 항상 테스트를 할때는 내가 어떠한 것을 확인하고 싶은가?에 대한 답이 명확하게 나와야한다.
6. 어디까지 테스트를 해야하나 의문이 든다면 구현을 위해 테스트를 하는지 테스트를 하기위해 구현을 고치고 있진 않은지를 확인해보자
7. 각 컴포넌트마다 관심사가 다르므로 이 컴포넌트에서는 어떻게 작동할까, 어떻게 사용할까를 생각하면서 테스트하자
8. mock functions를 범용적으로 사용하면 매번 테스트할때마다 같은 함수를 사용하므로 호출횟수가 누적이 되어 테스트할때 의도치 않은 결과가 나올 수 있다. jest.fn이 호출되었을 경우 초기화해주는 기능을 사용하자(jest.clearAllMocks())
9. TDD는 무조건 테스트 코드 먼저 작성하는것이다. Red-Green-Refactoring 순서를 항상 지켜야한다.
10. 리액트 컴포넌트에서 Red 단계는 컴포넌트의 인터페이스를 먼저 정의해주는 것이다. 테스트코드에서 props를 미리 넣어주고 렌더링 테스트를 해야한다. 그 후 실패를 확인하고 테스트코드가 통과하도록 컴포넌트를 만들어주고 중복된 코드가 없는지 확인하며 리팩토링해준다.
11. TDD에는 2가지의 간단한 룰이 존재한다. 첫번째로 자동화된 테스트에서 실패하지 않는 한 새로운 코드를 작성하지 않는다. 두번째 중복을 제거한다.
12. 테스트를 서술할때는 문장 그대로가 말이되어야한다.

자기선언

• 영어공부를 하자
• 관심사에 대해 항상 생각하자
• 이번주에 배운 테스트코드 내용을 잘 기억해두고 다음 과제에 적용하자
• 테스트할때는 항상 무엇을 테스트하고 싶은지에 대해 생각하자
• 구현을 위해 테스트하자, 절대 테스트를 통과하기위해 구현부를 임시방편으로 고치지 말자