[Practice Session 5] actionCreator test 질문

[kwonsunbin]

안녕하세요,

과제 진행 및 공부 중 의문이 들어 질문을 남깁니다. 아래 첨부한 실습 코드에서 actionCreator에 대해 unittest 할 때, 제가 이해하기로는 store.dispatch 이하의 부분에서 actionCreator가 제대로 동작하는지와 동시에 reducer가 제대로 역할을 하는 지까지 포함하는 것 같습니다. 이렇게 되면 unittest가 아니라 integration test의 의미를 갖지 않나요? 제가 잘못 이해하고 있는 것이 있다면 지적해주시면 감사하겠습니다.

[Algy]

네 사실은 맞습니다. 엄밀히 unit test를 하자면 getTodo_를 mock해야 맞고, getTodo_에 대한 테스트를 따로 짜야 맞습니다. unittest를 짰다고 생각하는데 실제로 integration test를 짜는 경우는 두가지인데. (1) dependency에 대한 판단 오류로 인하여 더 fine grained한 test를 짜지 못한 경우. (2) time budget으로 인해 일부러 짜지 않는 경우. 해당 슬라이드는 지면상 axios.get을 mock하고, 그것으로 state가 변하는 것을 한번에 보여주고자 이렇게 넣었습니다. 만약에 더 세분화를 시킨다면, (a) 이를 쪼개서, axios.get과 getTodo_를 mock하고, 이 데이터가 getTodo_에 제대로 전달되는지 (b) getTodo_가 spec에 맞는 action을 리턴하는지 (c) reducer가 이 action을 이용해 제대로 state를 변화시키는지. 이렇게 3단계로 테스트 할 수 있겠네요.

[Algy]

다만 해당 슬라이드와 같이 integraiton test를 하면 적은 코드로 많은 coverage를 올릴 수 있기 때문에 실제로는 이것이 간단하다면 이러한 방식을 많이 쓰기도 합니다. 어쨌든 integration test라도 있는 것이 테스트 자체를 안하는 것보다는 훨씬 낫기 때문이죠. 이 강의 및 개인 프로젝트에서는 unittest를 짜려고 노력하고 연습하고, time budget이 있는 실제 프로젝트에서는 적절한 방식으로 coverage를 올리는 것이 좋겠습니다. 또한 testing이 완벽할수록 당연히 좋지만, 완벽한 testing에 대한 심리적 부담 때문에 testing practice가 지지부진한 것보다 모듈들이 부분적으로 결합된 integration test라도 장려하는 개발 매니징적 측면이 있기 때문에 실제로 이름만 unit test인 integration test가 상당히 많습니다.

[kwonsunbin]

아 네 이해가 되었습니다. 친절한 답변 감사합니다!