221012 TIL 내 서비스는 믿을만한가?

오늘도 테스트 코드를 열심히 작성하던 중 초반에 비해 생각보다 테스트 코드를 많이 작성했다고 생각했었는데 동료의 테스트 코드 개수를 들어보니 다 작성하지 않았는데도 50개가 넘는다고 하셨다.. 잉??? 난 테스트를 다 작성한 것 같은데도 30개가 겨우 넘었는데 50개나..??

분명 같은 웹페이지를 만드는데 테스트 케이스가 한 두개 차이가 아니라 무려 20개가 넘게 차이가 난다는 건 내가 빼먹고 하지 않은 테스트들이 존재한다는 거고 그 말은 테스트로 검증된 서비스가 아닌데도 완성되었다고 착각하고 있었다는 소리다.

 

그래서 다시 작성하지 않은 테스트들이 있는지 확인을 하는데 역시나 예외 케이스에 대한 테스트나 초반에 모킹에 대한 어려움 때문에 하지 않았던 테스트들이 존재한 것을 확인했다.

 

우선 예외케이스에 대한 테스트는 회원가입이나 로그인 시 정보를 입력하지 않았을 때 테스트를 하지 않은 건데 이 테스트는 codecept로 E2E테스트를 진행했기 때문에 하지 않아도 착각을 했다. 하지만 당연히 단위 테스트에서도 해줘야 한다는 것을 깨닫고 예외 사항들을 테스트해주었다.

 

그리고 모킹을 제대로 하지 못해서 넘어갔던 테스트들은 컴포넌트의 구조를 바꿈으로써 모킹을 하지 않아도 테스트할 수 있게 리팩터링을 했다. 원래는 사용하려는 라이브러리들을 해당 컴포넌트에서 바로 임포트 해서 사용했기때문에 테스트를 하려면 모킹을 해야 했었다.

 

 

테스트하기 편하게 리팩터링 한 방식은 위 코드와 같이 테스트하려는 컴포넌트(LoginForm)의 상위 컴포넌트(LoginPage)에서 사용하려는 라이브러리들을 임포트 해서 props로 값을 넘겨주는 방식으로 리팩터링을 했다.

 

이렇게 리팩터링을 하니 LoginForm을 테스트할 때 모킹을 하지 않아도 전달받는 값들은 jest.mock이나 구체적으로 값을 써줌으로써 간단하게 처리할 수 있었다.

 

그리고 때 마침 디스코드에 모킹 때문에 테스트 코드 작성이 어려우면 설계가 잘못되었을 수 도 있다는 아샬님의 영상이 올라온 걸 확인할 수 있었다.

https://www.youtube.com/watch?v=RoQtNLl-Wko

영상의 내용처럼 구조가 잘못돼서 모킹 하는 것에 대한 어려움 때문에 테스트 코드를 작성하지 못하고 있었는데 구조를 살짝만 바꿔서 리팩터링 하니 테스트하는 게 한결 쉬워진 것을 경험할 수 있었다.

 

모킹을 무조건적으로 하려고 하지 말고 내 구조가 잘못되었는지부터 생각을 하자.