Custom Redux Testable

리덕스 패턴을 사용하면 여러가지 이득이 존재하지만, 오늘은 그중 하나인 "테스트"에 대해서 소개해 드리겠습니다.

 

글을 시작하기 앞 써 왜 많은 사람이 Test에 대해서 강조하는지, 제 개인적인 생각을 공유해드리겠습니다.

작성자가 아닌 다른 사람이 해당 코드를 수정할 때, 체크리스트를 제공합니다.

일하면서 가장 무서운 코드는 왜인지는 모르겠지만, 동작하는 코드였습니다.

다시 말해서 사이드 이펙트가 어디서 발생하고, 어디서 핸들링하는지 알 수 없는 코드였습니다.

이런 상황을 방지하기 위해서 우리는 해당 코드를 수정할 다른 사람에게 준수해야 할 체크리스트를 제공할 의무가 있습니다.

 

 

이것들만 확인하면서 고치면 됩니다 :)

Q: 그래서 어떤 객체를 테스트 해야 하나요?

여러 개의 객체 중에 Reducer를 테스트할 겁니다.

특정 Action이 발생했을 때 원하는 State로 변경하는지, Action이 발생했을 때 Side Effect가 발생하는지, 코드를 작성할 때 디자인한 흐름이 맞는지 확인할 수 있게 됩니다. (Predictable)

 

 

Fire and no effect

Side Effect가 발생하지 않는 경우는 테스트하기 쉽습니다.

Action을 발생시키고 예상되는 State로 변경되는지 확인하면 됩니다.

 

 

Fire effect

SideEffect가 발생했을 때 확인해야 할 사항은 크게 두 가지입니다.

1. Side Effect가 발생하지 않는 경우

비동기적인 이벤트로부터 이벤트를 받지 못했을 경우를 테스트하는 겁니다.

설계한 대로 메소드가 호출되는지 확인할 수 있습니다.

 

2. SideEffect가 발생한 경우

외부로부터 비동기적인 이벤트 신호를 받았을 경우에 값이 정상적으로 들어오는지,

새롭게 Action을 발생시키는지 확인할 수 있습니다.

 

 

---

 

말은 되게 간단하게 이거하고 저거하면 됩니다. 라고 표현했지만,

실질적으로 테스트를 준비하기 위해선 여러가지 작업을 하셔야할 겁니다.

(Reducer를 테스트하기 위해서 추상화도 시켜야하고 Mock 객체도 만들어야하고...)

개인적으로 테스트를 진행할 때 개인적으로 작성한 Redux와 라이브러리의 차이점을 피부로 느꼈습니다. 

라이브러리에서는 간편하게 작업할 수 있었기 때문입니다.