프론트엔드에서의 테스트 코드에 대한 생각

의식의 흐름으로 글을 써 본다...

 

조직 내에 QA 가 있지만, 때로는 QA 에 의존할 수 없는 상황이 생긴다

예를 들어,
1. 이미 다 통과한 QA 인데 리팩토링을 하고 싶거나
2. 잘 돌아가고 있는 서비스를 리팩토링 하고 싶거나
3. 아니면 이미 리팩토링을 해 버렸거나 (;;;)

 

소스 코드가 '더러운' 것을 알면서도, 경력이 쌓일수록 그 더러움을 그냥 참고 넘어가는 경우가 많아진다

 

그 이유는... 나 자신도 포함해서, 그렇게 코드를 작성할 수밖에 없었던 여러 이유들이 있기 때문이다

 

어떤 코드를 볼 때, 나중에 보면 '이걸 왜 이렇게 짰지? 멍청인가...' 라고 생각할 때가 있다

미래의 나는 그저 리팩토링을 진행하고, 그 결과로 나비 효과 같은 장애가 발생하기도 한다

 

이런 경험이 쌓이다 보면, 결국엔 문제가 있는 코드를 그대로 두게 된다

그리고 그 문제 코드를 방어하기 위한 또 다른 '쓰레기 코드'를 만들어내게 된다

 

리팩토링을 하고 싶은 강렬한 욕구가 들 때마다, 리팩토링에 앞서 개발자에게 자신감을 주기 위해 테스트 코드의 중요성을 느끼게 되었다

 

그리고 아래와 같은 의문이 들었다

 

1. 대체 프론트엔드에서는 e2e 를 해야 하나, unit test 를 해야 하나
2. 테스트 코드의 범위는 어디까지인가

위에 대한 해답을 얻기 위해서 문서를 찾아 보고, 라이브러리 개발자에게 메일도 보내 봤다

 

하지만 돌아오는 대답은... "상황에 따라", "프로젝트에 따라", "조직에 따라", "니 생각에 따라" ...

 

이런 대답을 들을 때마다 강의를 괜히 샀다는 생각이 들며 절망적이었다

 

하지만 최근 회사에서 관련하여 내 생각을 말씀드린 적이 있는데,
그게 맞다고 많은 시니어 분들이 말씀해 주셨다

 

테스트 코드에는 정답이 없는 것 같다

 

데이터에 기반한 백엔드 개발에서는 테스트 코드가 짜기 쉽다는 생각이 들었는데,

그것은 아니라는 대답을 들어... 놀라웠다

 

어쩌면 나는 제대로 된 시도도 안 하고 포기부터 했던 것 아닐까?

 

올해는 e2e 든 unit test 든 일단 테스트 코드를 짜고

자신감을 가지고 리팩토링을 도전해 보는 것으로 결심하였다