test-hae-boza zebal

대충 리듀서만 해봐야지라고 시작한게 셀렉터까지 했고.. 이제, 액션과 컴포넌트만 남았다..

리듀서와 셀렉터를 먼저 한 이유는

앱의 state를 저장하는 로직이 있기 때문이다. 컴포넌트에 그려줄 데이터가 셀렉터를 통해 가져오기 때문이다. 이 때 셀렉터는 단순히 스토어의 값을 뺴오거나, 가공하는 로직들이 담겨있다.

결국 두가지 다 app의 상태와 관련된 코드라 가장 중요하게 생각하여 먼저 테스트를 했다.

이러다 보니까 액션과 컴포넌트 중 어떤게 더 테스트 우선순위가 높을까라고 생각하다가 벨로퍼트님 글을 보았다.

대충 요약하자면,

리액트+리덕스 앱의 테스트 커버리지는 다음과 같이 하면 이상적이다

1. 프레젠테이셔널, prop에 따라 잘 보여지는지

2. 액션 크리에이터, 액션 잘 만들어지는지

3. 리듀서, 상태와 액션 전달시 의도한대로 업데이트 되는지

4. 컨테이너, 통합 테스팅을 통하여 의도한대로 되는지

하지만 현실적인건..

1. 프레젠테이셔널, 공수가 적고 걍 스냅샷테스트가 대부분일듯

2. 액션 크리에이터, FSA를 따른다면 할 필요가 안느껴진다. 단, 비동기 액션 함수는 테스팅 필요

3. 리듀서, 모든 액션이 잘 동작하는지 확인. 리듀서 테스팅은 복잡하지 않다.

4. 시간이 많이 없고, 1,2,3번이 잘 되어있다면 통합테스트도 할 수 있다. 컨테이너 컴포넌트의 버튼 클릭 됐을 때, 예상된 액션이 디스패치 됐는지.

   스토어에 값이 변경됐는지 확인할 필요 ㄴㄴ. 상태 관리 영역은 리덕스다.

리듀서 테스팅

• 나는 어떤 비동기 액션의 success type의 객체를 리듀서에 넣어주고 expect.toEqual을 통해 slice reducer가 가진 전체 상태를 전부 비교해줘서 조금 시간도 걸리고 귀찮았다.

• velopert에서는 액션 디스패치 되고 결과물 중에 필요한 프로퍼티만 검증했다.

expect(state).toHaveProperty('number', 0);

액션 테스팅

스냅샷으로 찍어놓자.

비동기 액션 테스팅

요청 시작/성공/실패 가 있다고 하자.

가짜 스토어를 만들고 api 호출 후에 성공/실패 2가지 상황을 만들자.

각각의 상황에 맞는 액션을 디스패치하고 스냅샷을 찍자.

컴포넌트 테스팅

버튼 클릭시 액션을 디스패치하는 게 있다고 하자. mock함수로 컴포넌트에 주입시켜서 해당 버튼 클릭시 목함수가 몇번 호출됐는지 확인하면된다.