소위 프런트엔드 그러니까 웹 애플리케이션은 왜 테스트하기 힘들까? 복잡하게 생각 할 필요 없다. 허구헌날 바뀌기 때문이다.

사용자 프로필을 출력하는 모달 컴포넌트를 떠올려보자. 여러분은 꽤나 신경써서 유닛 테스트도 작성했다. 신성한 초록색 바도 확인했다. 자 이제 PR을 보내볼까? 하는 순간 UI는 바뀐다(그… 그 정도는 아니야). 애써 작성한 유닛테스트의 3분의 1이 실패하고 테스트를 하나하나 고쳐야한다. 내일도 모레도 UI는 바뀌고 테스트는 다시 깨지며 또 고쳐야 한다.

시간이 지날수록 테스트 관리 비용은 크지만 얻을 수 있는 긍정적인 효과는 적다고 느껴진다. 점점 테스트와 거리가 생기기 시작하고 결국엔 이별을 맞이한다.

UI는 자주 바뀐다. 왜냐하면 가장 바꾸기 쉽기 때문이다(심지어 효과적이다). 그래서 UI를 테스트하지 않겠다는 의견도 어느정도 이해가 된다. 하지만 UI에 대한 테스트 포기가 곧 모든 코드에 대한 테스트 포기로 이어져서는 안된다.

힘세고 오래가는 테스트 전략은 간단하다.

우선 테스트하기 편안해야 한다. 즉, 거치적거리는 것 없이 유닛 테스트를 작성할 수 있어야 한다. 밥과 함께 씹히는 돌을 한번은 참고 넘길 수 있어도 만약 계속 반복된다면 여러분은 숟가락을 집어던질 것이다.

두번째로 상대적으로 덜 변하는 것을 테스트한다. 덜 변하는 것은 그렇지 않은 것에 비해 더 중요한 내용을 담고 있기 마련이다. 다시 말해서 애플리케이션 규칙이나 서비스 정책을 식별하고, 표현이라는 맥락에서 분리할 수 있어야 한다.

정리하자면 다음과 같다.

1. UI 컴포넌트는 개인의 판단에 따라 테스트 작성 여부를 결정할 수 있도록 한다.
2. 중요한 것(상대적으로 덜 변하는 것)을 식별하여 테스트 작성하기 쉬운 방법으로 구현하고 테스트한다.

어떻게 끝내야 할 지 모르겠지만 일단 하고 싶은 말은 여기까지다.

끝.